Initial structure for backend #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8f2cca8 to
70cc549
Compare
JulianKniephoff
requested changes
Jun 30, 2020
3c74aa8 to
676ac00
Compare
JulianKniephoff
approved these changes
Jul 1, 2020
This creates the file structure for most things we will need, with relatively small modules such that we don't need to split modules in the near future.
This gives us `Error` which is basically `Box<dyn std::error::Error>` but with a bit more features. It also gives us convenient macros and the `context` method which really helps making error messages more understandable.
Note: it is worth thinking about whether we want to
#[macro_use] extern crate log;
... or use some other way to have all logging macros available in all
files. It is super annoying to add an import for a logging macro every
time you add a logging statement.
676ac00 to
091a3b8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is some initial backend code (just the foundation). This was mainly developed as a small proof of concept project first and then transferred here. As far as I know, with this foundation, we can almost immediately start hacking on application logic (the interesting stuff) as all preparation work is done.
Not that we can't change this later, but here is a list of libraries/technologies that I (often in discussion with Julian) think, are good for our job:
juniper: a GraphQL library for Rust. It handles the parsing and partly the execution of incoming queries. In our POC code base it has shown to work great.hyper: our HTTP server library. Hyper is a fairly low level library that most other Rust HTTP and web frameworks are based on. It is extremely fast and well tested. But why this rather low level library? We won't use most stuff "nice web frameworks" offer and the HTTP part of the library will be very small (a few hundreds of LOC at most). So it's fine using this. Additionally, there is...juniper_hyper: a "glue" library that makes juniper integrate very easily in a hyper server. This library also offers "graphiql", a browser based GraphQL IDE/tool which is really useful. It is simply served from a path like/graphiqlto easy debugging.With this, the whole server is completely async. My initial tests (with a simple query returning 3 rows) show that the response time (on localhost, when the server is idle) is below 1ms and that tens of thousands of requests per second are easily possible. And (at least according to
/usr/bin/time -v) the peak memory usage is around 10MB, even when burn testing it with 400 parallel connections. That should be great for a potential test deployment server where we can just run hundreds of instances in parallel.I guess we will discuss this PR next week.