An application for worms to schedule space walks... in space.
docker-compose up worms_in_space --build
Now you can visit localhost:4000 from your browser to view the application or localhost:4000/api to play around with the GraphiQL Playground.
docker-compose up test --build
-
GraphQL: As an IC on New Relic's GraphQL API team, I've been deep in a GraphQL API for the last 3.5 years, and I absolutely love it. Under- or over-fetching data isn't a thing with GraphQL, you get only the data you ask for. GraphQL APIs are self-documenting and are strictly-typed, which makes querying for data as easy as tab-complete.
-
Absinthe: "The GraphQL toolkit for Elixir." Absinthe allows you to write your GraphQL schemas in Elixir code 🎉. Elixir has also been my life for the last 3.5 years, so having the ability to define and execute GraphQL queries via Elixir code makes spinning up APIs fast and easy.
-
Apollo Client: I love working with Apollo Client. The documentation is absolutely phenomenal, which makes it easy to get things up and running in no time.
-
React: React is my go-to for frontend developement. I most recently worked solely in React to build out New Relic's new comment panel functionality. This comment panel allows engineers to actively discuss errors and incidents in real-time directly in the New Relic UI. I love that React components are just like functions, which makes it feel quite like a functional language (and I love a good functional language).
-
Typescript: This was my very first attempt at dipping my toes in the waters of Typescript. I didn't get much of a chance to play around with it, but it seems like a safe choice, and I would love to learn more about it.
-
It's always satisfying to complete a steel thread. While it's fun to complete an entire piece of a project in isolation, (e.g. building out the entire backend before moving on to the frontend), the reward of seeing an effort through to completion, (e.g. hooking up a single backend query to a frontend component), offers more end-user value than having a full backend that a consumer can't interact with.
-
I truly love Frontend development! I plan to build out more of this project's frontend; it's so rewarding to see the things that you build on display and work at the direct customer interaction point.
-
Architecting a system before beginning the actual development always pays off... even if the final product doesn't match your initial ideas.
-
Well-defined criteria for completing a task or project makes all the difference.
- "GET request" for worm time slots, aka GraphQL query for
wormTimeSlots:
query{
wormTimeSlots {
id
startTime
}
}
- "POST request" to create space walks by
idoralternate_time, aka GraphQL mutation forwormSpaceWalk:
mutation{
wormSpaceWalk(id: 1, alternateTime: "2022-02-28T16:00:00.000Z"){
startTime
}
}
-
Querying the API for and displaying pre-defined times as radio buttons in the UI
-
Submitting a hard-coded mutation from the frontend that successfully console.logs a mutation response
What's next for the frontend:
-
Add a submit button to
wormTimeSlots.tsx -
Add an input field to accept an alternate time to
wormTimeSlots.tsx -
On submit, call the
wormSpaceWalkmutation with either theIDof the selected pre-defined time or thealternateTimefrom the input field -
Disable submit button if no selection is made
-
If an invalid time is submitted as an alternate time, display an error message
-
If everything is successfully submitted, render a success page!
-
Add a button to redirect users from success page to schedule another space walk
-
Separate functional pieces out into their own components
-
Add tests!
-
Use DateTime.from_iso8601 to verify that the
alternateTimeinput is in fact ISO8601 and return a GraphQL error if it's not -
In
Api.Resolvers.create/2validate that the autogeneratedIDdoes not already exist