How ready is Apistar for primetime?


#1

I just took APIStar for a spin and really like it. I liked Django Rest Framework as well, but this fixes a lot design choises I really was not that keen probably raising from Django itself.

How ready would it be to real project? I don’t mean functionality wise as it has what I need. I am more concerned do I need rewrite the app if I use Apistar now?

This is not a huge issue as it would be to use on a side project rather than billable customer work.


#2

I am actually working towards getting APIStar into production as is, but my workflow is not as efficient as it was when i was working with e.g. LoopBack. What could add a lot of value is more CRUD commands in the CLI which could auto-magically create views, models, components etc… Renaming and refactoring code is quite easy in LoopBack due to the predictable and well-defined structure of the application, while in APIStar, due to its early nature and open-minded philosophy, it will definitely become cumbersome to re-write stuff in my opinion, not that its different from Flask. While i honestly dislike NodeJS as a back-end, the way LoopBack organized the API and created the CRUD commands through the CLI is quite interesting. I would wan’t to experiment with that in APIStar, but it would have to enforce a couple of things in order to keep the structure, which in my case would be ok.

A reference to the LB CLI commands: https://loopback.io/doc/en/lb3/Command-line-tools.html


#3

I nearly forgot to mention the lack of migration tool. But it seems to be quite close to being available: https://github.com/tomchristie/apistar/pull/175


#4

I wanted to reply to this to pop it up in the stream again and see if anyone has experience with this in a production environment.

Do we have any live production users out there in the wild?


#5

I’ve heard from a coupla folks who’ve mentioned using it in production.
Working on getting something out myself too, and helping use that to direct filling in some of the gaps we’ve got at the moment. Expect to continue to see things progress over the coming weeks/months.

In general tho’ I think it’s hard to justify in a business context right now vs. say Flask.

One of the things that’ll help will be when we have options for deploy within Flask or within Django.


#6

@maziar good to hear I am not the only one liking loopback. I am not a fan of nodejs or backend js in general, but loopback is a tool that does what it says in the tin.


#7

I am currently running in production in a serverless environment, and it is working like a breeze. Hard to back to the good old server setups after this :slight_smile:


#8

How will you be (or plan on) using this with flask? Is this something already being worked on? Is there anything I can do to currently make it work with flask? I would love to know about this.


#10

I’m liking API Star so far. I was looking at flask API, but customers wants swagger API specs.

I also did have questions about how stable, how many people using it in production. And I also need to think how to deploy. I always deply flask behind NGINX with fcgi.

And I need to get my head around async mysql access, with some transactions. This is my lack of asyncIO understanding.

Sorry, just thinking aloud, but does anybody have thoughts?


#11

Here’s a brief experience report:

At Leadpages we’ve deployed one production service (a user metrics tracker) built with API Star so far and are currently working on the next one to be released in a couple weeks or so. The production service has been out for about 2 and a half months at this point and has been doing well. 0 production incidents and decent performance: it’s currently doing about 1RPS with a 99.9th percentile latency of 13ms, during my pre-release benchmarking it sustained 100RPS with a 99.9th percentile latency of under 30ms and a 99th of 20ms.

There were some rough bits during development and I often find myself diving into API Star’s source code to figure out things that either aren’t documented or are badly documented and we’ve had to write a few packages (apistar_dramatiq, apistar_prometheus, apistar_sentry) to trim some of the boilerplate between projects. Having to explicitly call out which properties are required (rather than them all being required by default) when using typesystem.Objects is a bit of a PITA. Other than that, the experience is pretty nice. The DI makes apps’ testing stories especially good.


#12

How is the experience now under the rewrite? Are you guys still moving ahead with deploying APIStar on other services?


#13

I have 0.3.9 in production somewhere, which works fine with stable sub 7ms @ 10req/sec performance.

Currently porting to the latest version which in terms of code does feel much cleaner around schemas, event hooks etc. Well done, Tom.

One of the things suddenly missing seems to be HTTP path and query string parameter validation, so if you need that, then maybe hold back.


#14

I accepted a new job since posting that, but, AFAIK, Leadpages has upgraded the two APIStar-based services to 0.5 and they are both currently running in production.

At my new job, we currently use 0.5 in production (having migrated from 0.3) for the main API and are pretty happy with it (though all the backwards-incompatible changes are begging to be annoying (for example, I just upgraded to the latest version and my custom validators started failing because Validator.error had added a new, required, positional parameter)).


#15

I am looking for someone to do a MVP for simple app and I would love to use apistar (with Postgresql and maybe asyncpg)?. I wrote up a spec.

Ping me if you are interested @ abarker@[—remove—]tempo.eu.com