Let’s Build a Web App! Week 11 out of 30

In which I get my frontend and backend communicating and build out components for the site’s skeleton.

Rona Chong
5 min readOct 16, 2017

Hey strangers and friends!

Here’s my weekly breakdown for what’s gone down most recently in my web dev journey. It’s Week 11 out of 30, and I’ve officially moved out of the research&planning phase and into developing (hooray!).

What’s that? You don’t know what I’m talking about and would like to? Well, for context, here are the previous posts for this blog series:

What did I set out to do?

This would be the second week of ‘Block 3’ (mean the third month of work / the second month on this project in particular). Block 2 was devoted to research and planning, whereas in this block I’m aiming to get an MVP done (a minimal homepage view, a minimal reader view, a minimal user dashboard view, and a minimal database view, all nonetheless functioning and usable). Originally, I aimed at getting the homepage view and the reader view done this week — however, the planning phase spilled over into this block (re: last week), so I’m playing catchup.

What did I end up getting done?

First half of the week:

  • I added a new model for a user status to my Django backend and created my first GraphQL mutation (CreateUserStatusMutation)
    (My plan was to work on the auth layer this week, and user statuses seemed appropriate enough feature to expose upon authentication)
  • I wrote some tests for my GraphQL schema and got them working (while also fixing my code — testing is useful)
  • I corrected some of my code to fix filtering functionality (i.e. I can make a GraphQL query for one of my models and filter by its fields).
  • I added jwt (json web token) middleware to my Django backend and React frontend

Second half of the week:

  • Finally started some React development, adapting the example app from the ReactQL start kit into the skeleton for moshimoji ヽ(・∀・)ノ. More specifically,
  • I updated the ‘helmet’ component with meta details for moshimoji.
  • I created stub components for the main views, or modules, of the site (home/site news, user/site dashboard, reader, database, forum, and doujin) and replaced the routes in the React router switch with routes to these components.
  • I configured my Apollo network interface for the frontend to make requests to my GraphQL server on the backend. (Apollo is a library you can use to manage query state and make queries to a GraphQL endpoint from React components.)
  • I wrote my first Apollo-connected component (yay!) — a component to display user statuses stored in my GraphQL server.
  • I created a component with logic to function either as a link (to a different site module) or a button (to pop up the login dialog) depending on the authentication status of the user (anonymous or logged in).
  • I created a ‘modal’ / pop up component for the login dialog and hooked it up to Redux such that its display gets toggled from the LinkOrButton I described above.

What went well / What was difficult / What I would do differently next time

What went well:

I haven’t counted the hours yet, but I definitely feel the difference between this week and the last two weeks, in terms of work productivity. It turns out that developing is a lot easier to work on steadily as opposed to mocking up views in Illustrator. Who knew.

So far every time I’ve gotten stuck on something (which has been pretty often), I’ve also gotten unstuck on my own within a few hours. I’m glad that all the functionality I’ve worked to add this week is working, and that I got a few milestones/firsts under my belt this week (GraphQL mutation, GraphQL filtering, GraphQL one-to-many querying, Apollo network interface, Apollo component writing, a higher order container component with dynamic logic).

Speaking of debugging,

I had an interesting time digging through various libraries I’m using in my backend (graphql, graphene, django-graphene, relay) while troubleshooting and learned a lot about what happens whenever my GraphQL server tries to resolve a query. I want to laud the graphql library for being especially readable and easy to understand. ☆

GraphQL schema introspection is useful.

Linters are useful and time-saving.

I’m also seeing how using a starter kit for my frontend (ReactQL) is saving me lots of time (even if I have to spend some time digging to figure out how things are configured and all that). Thanks to my mentor Nic Chan for the tip!

What was difficult:

I am encountering some of the downsides to hopping onto relatively new and exciting technology, including that the graphene-django docs can be a bit sparse, and the only resource I’ve found specific to my whole stack (Apollo-React-Graphene-Django) was written prior to the most recent update to Graphene (it took me a while to realize there’d been breaking changes in the new version!). Hence the digging around in libraries and also spending time piecing things together (how to manage one-to-many queries with GraphQL).

As usual, everything feels like it takes a while for me to figure things out for the first time (but on the other hand.. it feels that much more interesting and satisfying to manage something for the first time as well!).

Even though I only studied/tried out ES6, React and Redux best practices a few weeks ago, I found myself hazy on a lot of details and having to relook things up and so on. It takes a bit of rehearsal before you really pin things down, or at least it does for me. :/

What I would do differently next time:

Install a linter earlier.

Maybe separate my frontend and backend in separate github repos that can act as subrepos.

One cool thing I learned about:

When you specify one model (e.g. user) as a foreign key for another model (e.g. user status) in Django, graphene-django will automatically generate a query field for that one-to-many relationship for you, such that you can query for the set of ‘many’ objects related to ‘one’ (e.g. userStatusSet belonging to user).

Misc links for your browsing pleasure:

--

--