Lessons learned from an upcoming webapp

A friend and I finished developing a webapp (currently in staging, scheduled soon for production). Here are some of my learned lessons.

Mock server api AT server

Mocking the api between client and server allows both parts of the application to be developed independently. The server progress does not become a bottleneck for the client progress, and a mock can also be further utilized after the development of both is complete, for debugging puporses.

The mock can be implemented either at client or server.

  • At the client, this usually means trapping calls to the api, and delivering the appropriate mock data. With this method the call never leaves the browser. Libraries for this methods exist, for example Angular users have ngMockE2E/$httpBackend.
  • At the server, means you run a server that serves mock data for your client. Popular options include swagger and api blueprint.

The exprience of mocking the data at the server (with swagger), proved to be better than the experience I had with mocking at the client:

  • When using api spec tools you get your api documented nicely and a mock server all for the same price.
  • Sometimes, a bit of processing and logic is needed to deliver the right mock data. This kind of logic, is actually server logic. When mocking at the server, the mock logic can be shared with real backend application logic.
  • When choosing to trap api calls at the client, you get extra files laying around next to your frontend application files. These need special attention. They need to be bundled for development environment and excluded from production environment. In contrast, with a mock server, extra files for mocking is not an issue as long as they are not loaded in production environment.

Google Cloud Platform for the win

This was the first time I administered a kubernetes cluster intended for production use. I chose to go with gcloud simply by assuming a google container orchestrator works best with a google cloud provider. Since I was doing all the development, including ops, backend, frontend and db, I needed the easiest cloud solution to work with kubernetes. In a different scenario, I would inspect more and fiddle also with kubernetes on bare metal. Nonetheless, gcloud proved to be great:

  • Support- I had a problem with uploading images to gcloud container registry. It stopped working for me. After battling it for a while, I found a public email to contact the gcr team. I did not sign for any special support plan, yet within 40 minuets, I got a meaningful reply by a developer! (I eventually came up with a fix, more details at SO). Big ups for gcloud support!.

  • gcloud, gsutil are easy to work with.

  • The console (gcloud GUI), works nice, though can get buggy at times (some flows do not work for me in FF, chrome solves).

  • The docs tutorials: short and concise, with smart hooks if you need to dive deep into a subject.

    If you're hooked into AWS, keep it so. If not, give Google Cloud Platform a chance.

There's no 2 in TEAM

I have a tendency to think that if a project is small enough, a team of 2 will suffice. The problem with this approach is some skill will always be missing. I am a developer. If I choose to collaborate with another developer, then we might deliver a good, bug free, product, but then user experience will not be optimal, and we will be clueless when it comes to marketing. If I choose to collaborate with a non-developer (as in this recent webapp), we'll get good product management and marketing, but then there's no code reviews, and time estimation for tasks can get volatile.

3 is the new magic number, and a minimum for future projects.