Commit 8cf9def5 authored by Corey O'Connor's avatar Corey O'Connor
Browse files

Update README.md

parent 6546492d
......@@ -121,22 +121,63 @@ $ curl http://localhost:10000/openapi.json
### A Brief Tour
(go over the general types of default routes)
TODO: o over the general types of default routes)
- `_ops` routes
- `_ops` routes - routes prefixed with a `_`. These are automatically generated.
- `/$GROUP/_ops`
- `/$GROUP/$SERVICE/_ops`
### Groups
TODO: show dynamic instantiation of a group
### Service Fragments
(instantiate a service fragment)
TODO: show dynamic instantiation of a service fragment under a group
# Customization
glngn server provided a programmable application experience: All dynamic
operations described above can also be declared via Scala code. New service
fragments can be added as well.
## Deep Dive: On the use of an assembly
The default build uses an assembly, non-modular, glngn server library. This
provides a low complexity build for extensions that only need the included
libraries. See [the API documentation here](http://docs.glngn.com/latest/api/)
for reference.
Assembly distributions are considered "a headache the moment your users step
outside of Hello World". However, with glngn server those simple cases are often
useful and the convinience is valuable.
In addition, the provided glngn server assembly has a high degree of assurance
that is difficult to provide with a modular build (at this time). The
assembly is built and verified against specific versions of dependent libraries.
The non-modular build permits adding or changing dependents. However, this
invalidates the prior assurances to a degree.
## Using only scalac
## Using sbt-glngn plugin
Using scalac directly is nice but the recommendation is to use the `sbt-glngn`
sbt plugin. Very little code is required to start using this plugin. The
interfaces provided also support easily moving to the modular build.
When the additional complexity of a modular build is appropriate, of course. :)
This repository is a series of different customizations.
1. `starter-0` - identical to the default
2. `starter-1` - an additional available service fragment
3. `starter-2` - a default group with a service fragment already instantiated
4. `starter-3` - same as starter-2 but configured for kubernetes deployment
5. `modular-0` - same as starter-1 but using the modular libraries instead.
## Minimum build setup
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment