jtmarmon

join the slack chat. very active and helpful. even the facebook guys are there and I get to ask them about there nitty gritty closed source implementation details

> so that the front-end designer can decide which calls to make, and whether requesting [field2] is worth the cost.

How is this different in essence from an annotation?

It's also worth noting if you want to have guarantees that your front end engineer doesn't fuck up your performance terribly by making bad queries without them being analyzed or whatever, you can take the stored query approach (this is what facebook does - also good for preventing accidental data leaks) where you store each usable graphql query in a database, and hardcode the query's ID into your application rather than the query itself.

This is how netflix approached api gateways. http://techblog.netflix.com/2012/07/embracing-differences-in...

However, this approach is a giant pain in the ass and technologies like Falcor (netflix cannabilizing its own pattern) and (my preference) GraphQL will come to replace.

With a generic client side query language, you don't need to deal with versioning APIs, lots of concurrent development, overhead of deploying a new API for each client, the list goes on. GraphQL in front of a set of services is how we're approaching our next project and it's working really well so far.

Database servers - AWS RDS

Queue servers - AWS SQS

SSL termination - AWS ELB

Logging aggregator - depends on how you're deploying. We're deploying our containers onto elastic container service and adding one of these: https://github.com/gliderlabs/logspout to each instance. Elastic beanstalk will do the log aggregation for you

i might be wrong, but i'm fairly certain you have rights that you need to explicitly give up in the form of a license in order for it to be "free"

is there a reason for this existing other than the coolness? it can't be more convenient than setting up just about any actual nosql database

honestly what the world needs is a better ORM for node...sequelize is absolute shit

got it. so the idea is generally people want to do sort-of 2nd derivative queries on the data, so it's best to get those first stats out of the way in the warehousing step

Thanks for your input. The point of a BI tool is to allow flexible analysis of your data. What types of transformations are generally required for making this work without actually _doing_ the analysis during the warehousing step?

woah, right as a I wrote that edit I get this comment ;) very cool. checking it out

Sort of off topic, but every cool BI tool I can find (prompted by recently seeing metabase and AWS quicksight) seems to work with one database at a time.

When working with microservices, your data is spread across some N databases, rendering most BI tools, from what I can see, completely useless for reporting on more than one service at a time.

Are there any solutions for this? Or is the only one right now just dumping all your service DBs into a single DB for analytics?

edit: thanks friends. ETL it is. don't know why I thought it would make sense to have a tool that reports across multiple databases since the performance would be horrific...although maybe there's space for a hosted BI tool that does ETL automagically. just a thought

> "no one runs bare docker containers in Production"

can you elaborate on this?

agreed. i imagine it could get a bit cliquey. i think it almost certainly depends on the structure of the host engineering team and also its size.

> Keep in mind that these early people will have a huge impact on the community’s culture and values in long run.

amen. not only by how they conduct themselves/what they're interested in, but also in the people they help recruit

We're using datomic in production. It's had its ups and downs. For one, having raw data available at in-memory speeds really changes the level of expressiveness you have in your code; you no longer are constrained to packing every question about your data into a giant query and sending it off - you can instead pull data naturally and as needed. Many of our queries make multiple queries and are high performance.

The licensing is a huge pain in the ass. If I accidentally launch an extra peer over our license limit, our production environment will stop working until the extra peer comes down. This is really butting heads with the growing popularity of abstracting physical servers as clusters so I think the strategy is kind of a mistake on cognitect's behalf.