Skip to content

Latest commit

 

History

History
88 lines (66 loc) · 3.25 KB

README.md

File metadata and controls

88 lines (66 loc) · 3.25 KB

$name$

This project creates a GraphQL-based service that provides access to a user database, of the type that one might find as the basis of any authorization subsystem.

running the service

local Docker

One can publish a local Docker image in the usual way (that sbt-native-packager uses):

sbt docker:publishLocal

The server listens on port 8080. Deploy it in the usual way:

docker run -p 8080:8080 $name;format="normalize"$

Using the above port number, http://localhost:8080/graphiql should return the GraphiQL UI when viewed from a browser.

documentation

API documentation of the included classes is available in the usual way by running:

sbt doc

implementation

Besides GraphQL, the technologies used to implement the service include:

  • Scala, a mixed-paradigm, object-oriented and functional programming language with an expressive type syntax and compile-time type checking

A collection of Scala libraries that use functional programming with effects:

  • Caliban, for implementing a GraphQL server and client

  • http4s, for implementing HTTP server interfaces

  • GraphiQL, a Web-based UI for testing

  • Liquibase, for database schema generation and versioning. (This only works for JDBC-compatible databases.) There is a change set file that can be modified by the user.

  • PureConfig, for software configuration.

  • Scala Logging, for logging API.

  • Log4J2 with YAML configuration, for logging backend.

  • Docker image generation and publication

There are also points of variance, where a particular technology can be selected from those available:

  • The database may be one of:

Selection can be made in build.sbt using the available setting keys, e.g.:

import SangriaExample._
database := H2

See the SangriaExample class for the available settings.

updating the project

This project is generated from a template. The code in template.sbt and the sangria directory should not need to be changed by users of the template. If that's not true, point that out to the maintainers.

As such, one should be able to replace these files with those generated by a future version of the template that's been given the same parameter values. (This isn't a guarantee, but it is a secondary goal of the template project.)

license

See docs/template-license.md.