Update Interchange screenshots and add note on implementation
This commit is contained in:
Binary file not shown.
|
Before Width: | Height: | Size: 1.5 MiB After Width: | Height: | Size: 2.8 MiB |
@@ -14,3 +14,21 @@ GraphQL, with Redis as a primary storage mechanism.
|
||||
[Join the TestFlight](https://testflight.apple.com/join/HbuHfUgW){: .secondary-action }
|
||||
[Website](https://interchange.bchen.dev/){: .secondary-action }
|
||||
{: .horizontal-wrapper }
|
||||
|
||||
## Design and implementation
|
||||
|
||||
The server is built using Node.js. I designed a basic GraphQL schema and
|
||||
used [Apollo's GraphQL implementation](https://www.apollographql.com/docs/apollo-server/getting-started)
|
||||
to bring it to life.
|
||||
|
||||
In GraphQL, data is represented using a schema, which is then fulfilled with
|
||||
resolvers defined in code. Each resolver function gets some information like the
|
||||
parent object, arguments, and a server-defined shared context. Seeing the dependency injection
|
||||
that you could do with this context, I decided on an object-oriented approach consisting
|
||||
of **loaders**, **repositories**, and **systems**. Loaders load data from an external source,
|
||||
repositories store data, and systems are composed from a set of both loaders and repositories.
|
||||
|
||||
I then applied an event-driven pattern to implement the iOS notification sender, listening
|
||||
to updates on the shuttle repository. I would eventually reuse this pattern to implement
|
||||
**a custom ETA system** that could run independently of an external data source.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user