It depends what you're getting out of it. I've signed CLAs because it was more convenient for me to have my PR upstreamed rather than maintaining a fork.
520 karma · joined February 23, 2013
Site: https://www.even.li/
Equivalent delete queries in rest / graphql would be
curl -X DELETE 'https://api.example.com/users/123'
curl 'https://api.example.com/graphql?query={ deleteUser(id: 123) { id } }'For example I have bought these bottles https://www.zefal.com/en/bottles/545-magnum.html three times over ten years:
- the first time, the mouthpiece was attached by two plastic prongs. The prongs eventually failed
- The second time I bought them, the mouthpiece was attached by four prongs
- The last time I bought them, the hard plastic mouthpiece was replaced by a more comfortable plastic mouthpiece.
I also bought these pedals three times https://www.lookcycle.com/fr-en/products/pedals/road/race/ke... :
- With the first version, small rocks got stuck between the carbon spring and the body of the pedal, making it impossible to clip in and eventually dislodging the spring
- The second version fixed that by adding a plastic cover over the spring, and also improved the bearing seals (which was also a problem with the first version)
- The third version made the angles on the outside of the pedal less acute, making it harder to damage the pedals in a fall
They can do aggregations much faster and can deal with sparse/many columns (the "paid" event has an "amount" attribute, the "page_view" event has an "url" attribute...)
Although it works and is solid, I wouldn’t say it’s fantastic. My impression is that Google makes limited investment in it to steer customers towards their own services such as Cloud Spanner.
- Major versions are 6 months late - Small instances are horribly slow - Integration with other services is poor (e.g. the Cloud Run integration doesn’t work with a database private IP, so you have to fallback to configuring a VPC and connecting the standard way) - IAM authentication, although great when it works, is complicated and poorly documented - The UI has very few features, for example it isn’t possible to query the database from it - Although I’ve never seen any provider have it, automatic upgrades between major versions would have been nice.
e.g. :
type zero = []
type Inc<N extends string[]> = [...N,'']
type Dec<N extends string[]> = N extends [...infer T,''] ? T : never
type one = Inc<zero>
type two = Inc<one>
type oneb = Dec<two>With an ec2 instance, how do you, for example, update the Java version? Store the database password? Add URLs the service is served at? If it’s done manually how do you add a second instance or upgrade the os?
Though, I agree the infra setups are usually overly complicated, and using a “high-level” service such as Heroku or one of its competitors for as long as possible, and even longer, is usually better, especially for velocity.
select array_agg(e) from jsonb_array_elements_text('["a","b"]'::jsonb) e;
?On the other hand, when I have to do a somewhat complex query in Elasticsearch, or MongoDB, or gorm, or Django ORM, I have to check each time in the docs how it's done.
The situation could certainly be better, but at least this works today.
It does, this schema works:
type Item {
id: ID!
children: [Item!]!
}
type Query {
root: Item!
}
The main benefit to us is that it's a huge time saver. There is almost no similar/duplicated code for similar operations (for example search, list and get operations). It's also very easy to write a generic API once, without thinking to much about how the clients will use it, and have it used in ways that weren't anticipated at the time it was written.
It's also pretty easy to have the API made of entities that are always the same, rather than having routes that return slightly different data.
Another benefit is that the default / basic tooling works well and with no setup. The playground works, it's easy to generate idiomatic clients in many languages, which is not really the case with openapi or grpc.
However, although I have no data to back this up, I feel that the adoption is not that high, and more advanced or unusual tooling doesn't exist or isn't very good or progressing.
Another problem is that developers don't seem to grasp the best practices intuitively and the docs don't make it very clear what they are, but it's necessary to use them to have a useful API and not a slow, more complicated version of REST.
A GR isn't a geographic object, it is a sequence of trails that has been arbitrarily chosen by the author among all the possible sequences of trails.
- the data passed from one query to the next still needs to move from the database process to the service process and back
- the queries will always be executed in the order they are in the code, denying the optimizer the opportunity to execute the full query in the best order
I'd say it would result in either:
- the same scalability and availability with fewer DevOps engineers - better scalability and availability with a similar number or more DevOps engineers
In my experience, it's almost always the second case that happens. For example, a service would be moved from a few (virtualized or physical) servers that can only be scaled manually, to a k8s cluster with either autoscaling or at least scaling by changing a configuration file.
However, as you have noticed, all of these things are far from the standard. No tests, code that barely works, devs that are barely able to code, etc. is the standard in many companies.
The people I know who are competent and motivated go down one of two paths:
- either work for a company that values and applies best practices - or work for a company that doesn't in a role such as an architect, where they have a lot of freedom in what they do, and spend most of their time finding simple ways to make poorly written applications work or writing POCs or starting new projects
To answer your questions:
> I wonder if I'm just holding my peers to standards that are too high? Is it too much to expect tests? Is it too much to expect to be able to test full stack locally?
All of the standards you mention are best practices and are uncontroversial in the sense that they require little engineering effort compared to the benefits they bring.
Whether it's too much to expect or not depends of the context: if management or the more senior developers don't value it I'd say it's too much to expect.
However, if your colleagues aren't opposed to it or it's a school project I'd try to introduce improvements, starting with small things. For example, for the main branch that doesn't build you can explain why it's a problem (e.g. your colleagues will pull main before starting to develop something, and it's not nice to them to leave the project in a state where they have to fix things first), and introduce a solution (for ex. a CI job or a pre-commit hook that checks the project builds).
> Am I an arrogant or am I surrounded by incompetent people?
Some people value other things more than software development, don't mind repetitive work, are less driven, or even less intelligent and it's perfectly OK for them to be this way. So I'd say you're arrogant by judging them too harshly or expecting them to be different. However that's not the important part (though it's still a life lesson that I learnt much too late).
The most important part is that you should surround yourself with competent people so you can have more satisfaction in your work and learn new things.
_.chain and .value() could be removed
> works fine.
- it isn’t possible to tree-shake the package and only include the lodash functions that are used - it isn’t possible to have non-lodash functions in the pipeline (e.g. date-fns)
The 99% case is a pretty string. The 1% case is a string with escaped delimiters.
Chalk’s purpose is to color things printed to the terminal. Unless it’s performance is atrocious, which I doubt, it doesn’t matter unless a ridiculous amount of data is printed.
> Chalk maintainers also say tree shaking doesn't matter in the real world
No, they say it doesn’t matter for chalk’s use case. Which is command-line tools that are almost never tree-shaken.
Common ways to solve that are to whitelist the allowed queries or to cache at the resolver level instead of the query level.
LoadData(&data)
Does this function return nothing or an error ?
With a REST API, the “resource” type will always have an optional “comments” field, whatever the value of arg is.
With a GraphQL API you’ll have the right type depending on your query.
A pretty common use-case I have is needing to support these three things :
- A “big object” list screen (where retrieving the whole objects would make the query return megabytes off data)
- A “big object” details screen (where I need the full object)
- Programmatically getting many big objects
With GraphQL it involves writing one (or two) straightforward queries, while with REST it would require more thought or code.
How do you easily write an endpoint that can either return a comment, a comment with its children, a comment with its corresponding story, with a strongly typed schema (ie. no optional children or story whatever the query is)?
Not many people are locked up for a few years for a traffic violation
The test portal "not responding" when receiving an unexpected file format is a quality issue. Not making it clear to the user that the upload has failed before it is too late is another quality issue.
They are. You're only affected if you don't use a package-lock.json or start a new project (which will pull the latest versions of the dependencies).