Document architecture design decisions.

.adr-dir

+docs/architecture/decisions

docs/architecture/decisions/0001-record-architecture-decisions.md

+# 1. Record architecture decisions
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+We need to record the architectural decisions made on this project.
+
+## Decision
+
+We will use Architecture Decision Records, as described by Michael Nygard in  
+this article:  
+http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
+
+## Consequences
+
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see  
+Nat Pryce's _adr-tools_ at https://github.com/npryce/adr-tools.

docs/architecture/decisions/0002-use-elasticsearch-for-fulltext-search.md

+# 2. Use Elasticsearch for fulltext search
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+We need a database with fulltext search capable of searching in various  
+languages especially in Czech.
+
+## Decision
+
+We will use Elasticsearch. It's well known database with great fulltext search  
+capabilities based on Apache Lucene. It has also aggregations, highlighting of  
+results, and many other useful features.
+
+We will use it as database for all data so we have just one database in the  
+system.
+
+## Consequences
+
+* Great fulltext in any language.
+* Some extra work on application level with management of database relations,  
+  because Elasticsearch is not relational database.

docs/architecture/decisions/0003-just-api-without-frontend.md

+# 3. Just API without frontend
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+Open Lobby must have open stable API.
+
+## Decision
+
+Open Lobby will be server just with an API based on API First design. Frontend  
+will be written as separate application (web based, mobile, ...). This will  
+ensure that there is a working API for anything that frontend application(s)  
+will do.
+
+## Consequences
+
+Extra work with API layer capable of everything.

docs/architecture/decisions/0004-graphql-api.md

+# 4. GraphQL API
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+Open Lobby Server will be written in API First design. Frontend applications  
+will be based on it's API.
+
+## Decision
+
+We will use GraphQL as API standard. From other options like REST and Graph API  
+it's the most client friendly approach. GraphQL query language is easy to use,  
+validated and self documenting.
+
+GraphQL allows clients to get everything they need in one request without any  
+overhead of not needed data. That is very important for mobile frontends.
+
+GraphiQL tool also provides easy way for developers to inspect and try API. So  
+it's easy to adopt by frontend applications developers or other API users.
+
+## Consequences
+
+* Clients can use API effectively.
+* GraphiQL tool for free.
+* Saves a lot of time of writing API documentation.

docs/architecture/decisions/0005-python.md

+# 5. Python
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+We need to choose main programming language for this project.
+
+## Decision
+
+I'm now fluent in writing Python and JavaScript. Both languages are widely used  
+these days and may attract developers to join this project.
+
+Python is more mature with more stable libs for writing server side code and  
+testing. JS may have better libraries for writing GraphQL APIs because  
+GraphQL originated in JS ecosystem.
+
+I'm doing this in free time and for fun. I want to focus on project's features  
+and not to waste a time with poorly designed language lacking mature and  
+stable libraries. So for obvious reasons I'm choosing Python.
+
+## Consequences
+
+* Some people will love this decision.
+* Some people will hate this decision.

docs/architecture/decisions/0006-use-flask.md

+# 6. Use Flask
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+We need to choose webserver.
+
+## Decision
+
+We will use Flask. Server should be simple - pretty much just with a GraphQL  
+endpoint and GraphiQL.
+
+## Consequences
+
+Flask has "no batteries included" so we will have to rely on third-party libs  
+if we want to extend server later.

docs/architecture/decisions/0007-adopt-graphql-relay-specification.md

+# 7. Adopt GraphQL Relay specification
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+We need to make API friendly for clients and design pagination.
+
+## Decision
+
+We will adopt GraphQL Relay specification. It solves pagination so we don't  
+have to reinvent a wheel. It has handy Node interface for re-fetching objects.  
+It has a way to define inputs in mutations.
+
+Graphene lib has good support for creating API following Relay specifications.
+
+## Consequences
+
+* It will be easy to write SPA in JavaScript because it has Relay client lib.  
+* It may require some extra work to fulfill Relay specification.

docs/architecture/decisions/0008-pytest.md

+# 8. Pytest
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+We need to choose framework for tests.
+
+## Decision
+
+We will use Pytest. It's much more Pythonic and simplier to use than Unittest  
+from standrd library.
+
+## Consequences
+
+Writing tests will be easy and fun.

docs/architecture/decisions/0009-openid.md

+# 9. OpenID
+
+Date: 2017-11-11
+
+## Status
+
+Accepted
+
+## Context
+
+We need an authentication mechanism for users. It must be secure and  
+frontend application independent.
+
+## Decision
+
+We will use OpenID Connect. Open Lobby Server will provide all the hard stuff  
+for a frontend applications. Ideally over the GraphQL API.
+
+## Consequences
+
+* We can create a user account simply on the first successful login.
+* We don't have to verify user's email and to deal with situations like a lost  
+password.