Friday, November 16, 2018

My Guidelines for designing a restful APIs so frontend devs won't ask where I live

As a backend developer, I have to play nice with the frontend people. Let's face it, I don't want to be prison shanked on the lunch line. Easier said than done because of the different ideas that people have floated around like these three.
Each one of these have pros and cons but those are academic papers that I don't care to write right now. But I've worked and talked to a lot of frontend devs and they don't really care if we use any of the three examples that I gave. 

For them, a good API:
  1. Is well documented - makes sense; I'm a fan of drfdocs. Also Swagger gets a lot of mentions.
  2. Is versioned - good point; because changes to existing ones break too many things
  3. Is idempotent - to be honest I had to look this one up but it's the same idea of pure functions. Given the same input, it should return the same value (output)
  4. Uses HTTP errors correctly - For example, don't return errors with 200 status. Oops.
  5. Uses HTTP verbs sensibly - they want none of that 'GET /v1.0/delete/100' because that shit is stupid.
  6. Is NOT SOAP - dear lord up above in heaven, not ever SOAP. Ever
I also don't like SOAP. 

Thursday, October 25, 2018

2 months into Flutter

So I've been learning Flutter trying to get in deep. I'm been using Flutter for make an Android app and so far, I'm largely impressed but I have met a few small annoyances.

The good. 

1. Hot reload is the killer feature. I won't be a happy mobile developer if have to wait for the damn AVD to restart to see my changes. 

2. Android Studio support. I'll have to disclose that I'm also a Pycharm user so you could say this is a biased assessment. I've tried Flutter with VSCode, it works but having to manage the Android stuff like AVDs manually is a pain.

3. Good looking apps fast. Once you figure out how the layout system works along with the theming system, you'll have a blast creating your app UI also tweaking it.

4. Aside from good looking app, you also have nice responsive apps. Although I have to admit, the app I built didn't have that many moving parts.

The bad.

1. Dart. The language is like Java and JavaScript had a bastard child. Being a Python dev for the last decade, the curly braces just irks me. Also, it has a lot of optional syntax rules that bug me. 

2. The learning curve. Flutter isn't particularly easy especially for those without CS or programming training or experience. For example, how it handles databases and API calls is via Futures; Learning how to use Futures isn't trivial especially if you want a maintainable code base.

3. Missing key IDE features. The feature I'm taking about is the "build" feature. If you are using Android Studio, you'll still be forced to use the command line to build your final release APK. You can't do this from the IDE. May be the future.

I got nothing if you're an IOS developer.

Conclusion:

Flutter works although it has some of rough edges. I'd like to think these rough edges are teething problems. I expect a couple of these rougher edges be polished away before the end of year. I'm liking Flutter so far and I think I'm in good company - Alibaba used Flutter for their Xianyu app.

Friday, August 17, 2018

Cleaning up your global NPM packages

Sooner or later when you're working with any web app, you'll have to deal with nodejs because frontend requirements will force you to do so. And sooner or later, you'll have a mess of npm packages in your global space. You'll want to clean it up but when you issue the command npm list you get a whole mess of packages with their dependencies.

However there's a useful trick you can do that will make npm only list the top level packages without their dependencies.


$ npm list -g --depth 0


Here's a sample result:

The trick is the --depth 0 parameter. It suppresses the listing of a package's dependencies.

We can now tame our unruly global npm packages.

Ha!