2018 November - Projects Log

Hitting the nail hard with building a good toolset for server applications using GraphQL, I continue to press forward in tutorials, with the hope of using it, server and client, for my Geneology app's better implementation

2018 November 1, Thursday

Big moment in following the GraphQL Tutorial I've been using - I successfully hosted a database locally on my computer, and interacted with it using Prisma (which looks awesome) and its GraphQL Playground. I managed to locally host it using Prisma's documentation all from my laptop using docker-compose, and by tweaking the config, I was able to connect pgAdmin to the backing PostgreSQL database that Prisma interfaced with. I could follow a tutorial, but I like to customize, inspect, and tweak to be sure that I have a solid handle on what I'm learning. Since I can see the underlying data as well as the database, I'm both impressed and comfortable that I can continue forward. I study Prisma not because I even want to necessarily use it to interface with ArangoDB (which even could be subject to revison), but because it gives me insight into a solid approach for using GraphQL to interact with a database, and I hope to draw inspiration from its api to construct my own system. There's even a possibility that Prisma will get ArangoDB support eventually, which would of course be awesome. Through a mishap in the config, I lost the 2 table records I created by not specifying the database volume to be backed by my filesystem. I'll try fixing that soon.


2018 November 5, Monday

Tonight, some of my learning is paying off - I added GraphQL to my Genealogy project. I'm using apollo-server-express, which allows me to use it with most of my old server setup, but I have a clear path for migration from REST to GraphQL, and I'm writing the schema and resolvers in the best way possible. I verified that I was able to use GraphQL playground, served from my web server, to return data defined in the resolver functions' return values. No database connected yet, but I plan to do that soon, and I still have yet to figure out exactly how to use data-loader to do database fetching right with ArangoDB.


2018 November 6, Tuesday

Tonight, I had bare minimum database data returning from ArangoDB. Not all the GraphQL fields for the data are returned, but I have yet to debug them. The challenges here were using AQL for the first time, which I think will let me get better performance than making multiple round-trips for information mapping an array of id's to an array of results for each id, like DataLoader expects. Eventually, I hope to fix the other fields and serialize my enums properly.


2018 November 7, Wednesday

Tonight, I fixed all the non-graph-transversing fields on my "Person" type, and they all seem to work. My data isn't perfect, so most of those fields are nullable, but I should be able to use this. I hope to do relational data soon.


2018 November 8, Thursday

A great evening tonight - I finished relational data for Persons, giving the graphql endpoint the ability to transverse to a person's parents, spouses, marriages (including date married), and children. The biggest pain was all the AQL learning I had to do to get this to work. I found great help from the example queries and documented functions. I found that once I figured out the rough idea, it was very easy to get a working query that got the data I wanted. I trust DataLoader to help me strike a good balance between performance and programmer time. I've been keeping up with doing some small refactorings as the architecture for this app emerges, and have a few ideas for more I can do, especially in regards to where the loaders get created.

I did some thinking about the database communication layer, and I suppose some (including myself) might think I would find it a pain to write in AQL, which is basically what people call "handwritten" SQL, as if nobody wanted to use it directly and rely on ORMs. Writing queries is a bit of a pain, and for typical servers, I would try to avoid it, but this is different. Since all I need to write is the database used by an individual GraphQL field resolver, the queries are simple and focused. I actually like that I can mentally take the small chunk-like resolver semantics that GraphQL splits a server API into, and carry them down to the database layer. I cannot imagine a simpler way to do things, with everything having its own focus.

At this point, I can query all the same data that my old REST api was capable of, so I can move on to the frontend, and play around with Apollo Client, which I expect to be less work than Redux, granted that most of my state finds its source from a GraphQL server. I still place Redux as a best-of tool when an appreciable fraction of a web app's state lives on the client side only, but I don't think that's the case here. One may also wonder about Relay; a couple of blog posts are enough to convince me that Relay is too opinionated for GraphQL and has less features. Apollo also seems to have more ecosystem usage than Relay. I might be able to learn some things from Relay's ideas, in particular Connections, so I won't completely shut it out.


2018 November 12, Monday

I started a new outline view, a rewrite of previous work. I added the Apollo GraphQL client, and it seems to be compiling with a test query fetching data. I also added a field to make it easier to get a spouse's information from jumping across a Marriage link.


2018 November 13, Tuesday

Great progress, though I had to stay up until 1:10 AM to do it. I can now expand the outline over recursive componentns to view the entire data set! The Apollo GraphQL Client made this much easier to pull off by automatically managing the fetching progress, and changing my mind about what data I wanted to use was as easy as modifying the client side GraphQL query, with no server changes necessary! I feel as if I was able to do it with about 4 times as less code as before, and the server supports many more use cases than I had originally built.


2018 November 14, Wednesday

I had wanted to get one mutation in, but that will have to wait until next time. I did a little refactor on the server side to separate my DataLoaders from the storage layer, so that I could control cache more from the GraphQL layer. I'm also seeing some pain points with Flow, though I can see how it would still be useful, and to be fair, they may be a pain of static typing in JavaScript in general. I also made the UI prettier and easy to use - I'll have to make sure I don't get too un-maintainable with all these prototypical inline styles...


2018 November 15−24, Saturday

Batch update - ton of things got done without many in-between updates, I'll just have to summarize. I can edit people (without history), and I have built-in and tested server-side addition of children. That's 2/4 of the basic features done on the server side, the other two being marriages and parents. Perhaps I should eventually add Churches as well. I've been refactoring and rethinking architecture as the project grows, which I think is the best way of building something. Always, there needs to be thought for the big picture. One can delay that sort of work for a while, but not very long, lest it becomes harder to maintain in the future.

I also, with the sale of a larger hard drive that I didn't need replaced by a smaller one, I re-setup my server laptop, and managed to upgrade Ghost (this blog platform) while I was at it. Docker is wonderful in how ephemeral the non-data portions of a service or application are allowed to be.