If you're looking for a gitops alternative that can make use of AWS KMS, Azure KeyVault and Google Cloud KMS, would highly recommend kamus (https://kamus.soluto.io/). Allows secrets to be safely managed in source control and also has an AES mode ideal for local development.
Readit NewshurricaneSlider commented on First Impressions of GitHub Codespaces aristotlemetadata.com/blo... · Posted by u/legostormtroopr
> so I can use Windows tools like Unity (Editor just runs the best on Windows)
Wasn't Unity a Mac exclusive tool to start out? I know they have support for Windows at this point, and would understand if they've refocused on Windows since then.
Unity feels like it runs best on Windows to me. Metal bugs caused quite a few Unity issues for me when I was developing on a Mac. That was a year or so ago, so maybe the situation has improved.
Also a lot of useful 3d content creation software is Windows only, or only supports CUDA acceleration, so implicitly rules out Mac from being a first class citizen (e.g. substance painter)
Obviously not every game is the same, or needs fancy tooling. But Windows feels like it just works for game dev.
hurricaneSlider commented on GraphQL Query Generator blog.graphqleditor.com/gr... · Posted by u/oczek
The biggest pains with hasura are managing migrations across a large development team and adding business logic.
That's fair. I haven't used it in that context.
hurricaneSlider commented on GraphQL Query Generator blog.graphqleditor.com/gr... · Posted by u/oczek
We're looking at adopting GraphQL and for writing a CRUD app it seems insane. Being able to project out individual fields seems like a niche benefit for bandwidth constrained devices. Instead of doing joins in an RDBMS you write a dataloader which merges select queries. The queries themselves seem like a lot of repetition in the client codebase, plus the complexity of the server-side implementation.
Am I alone in thinking this is a ridiculous solution to replace traditional REST endpoints?
Have you looked at Hasura (hasura.io)? Allows you to carefully expose your database as an API, while allowing you to build serverless endpoints for validation, business logic and side effects. Bakes in authorization as a first class concern. There are some other similar alternatives that do much the same.
Think it's a mistake to consider GraphQL as a drop-in replacement for REST, writing a vanilla GraphQL server is indeed quite arduous as there is a lot of important concerns like auth that you don't get out the box.
But if you're just wanting to expose your database in a controlled and secure manner, with a smattering of business logic, think some of the technologies that have evolved around GraphQL like Hasura and PostGraphile can make it a joy to use.
Think the wonder is that the schema definition language/schema introspection wasn't just tacked on at the end (unlike REST w/ Swagger and OpenAPI) so all these tools have developed around the tech. There is also a bit less of an object relational mismatch than in REST.
hurricaneSlider commented on “This resentment runs deep and is stunningly widespread” daringfireball.net/linked... · Posted by u/mortenjorck
Seen a lot of comments to the effect that 30% is not a lot.
But what about corporate taxes, what about things like the game engine getting a cut (often an additional 5%), etc?
Apple Developers end up getting a slice of a slice.
That 30% is large enough to make whole business models unviable. You need 30% more sales or raise prices commensurately. That's a lot.
You'll probably have to spend more on customer acquisition to achieve those numbers as well as you start to eat into the long tail of customers. This eats into profits.
The cut probably also impacts the quality of experience, particularly for things like freemium games, as you need to monetize more aggressively to make up for the Apple tax.
> A restful API also has the problem that if you want fine grained auth, you'll need to remember to add the policy to each controller or endpoint, so not that different.
This is dependent on the framework, just as it is with GraphQL - for example, with ASP.NET Core you can apply an auth policy as a default, or by convention.
> Despite efforts to ensure that filtering was fairly generic, there was a lot of adhoc code that needed to be written to handle filtering.
I've never seen this problem with REST backends myself, but I work with a typed language, C#. Again though, this is more of a framework thing than a REST/GraphQL paradigm thing.
The transport API I was referring to was written in .NET Core. I think .NET core is great at what it does, but runs into the same kinds of problems that GraphQL tries to address from the start once your API becomes sufficiently featured, which is likely to happen if you're offering an API as a service.
I actually think that unless your company is massive or has a lot of expertise in GraphQL already, using it for private APIs may not be the best idea, as it could be a sign of certain internal dysfunctions or communication problems within or between engineering teams.
----
An example, however of the kind of filtering I was referring to, and why I still think it would be non trivial to do, even in something like ASP.NET, is the following: https://www.gatsbyjs.org/docs/graphql-reference/#filter. This of course isn't something you get out the box in GraphQL either, but the structure of the system made this (relatively) easy to do.
Of course you could add something like OData to your REST API which would definitely be a valid alternative, but that also would have its own warts, and is subject to similar criticisms as GQL.
> I don't understand the attraction to Graphql.
It's attractive primarily to frontend developers. Instead of juggling various APIs (oftne poorly designed or underdesigned due to conflicting requirements and time constraints) you have a single entry into the system with almost any view of the data you want.
Almost no one ever talks about what a nightmare it becomes on the server-side, and how inane the implementations are. And how you have to re-do so many things from scratch, inefficiently, because you really have no control of the queries coming into the system.
My takeaway from GraphQL so far has been:
- good for frontend
- usable only for internal projects where you have full control of who has access to your system, and can't bring it down because you forgot an authorisation on a field somewhere or a protection against unlimited nested queries.
> usable only for internal projects where you have full control of who has access to your system, and can't bring it down because you forgot an authorization on a field somewhere or a protection against unlimited nested queries.
As someone who is building a public facing GraphQL API, I would disagree with this. Directives make it easy to add policies to types and fields in the schema itself, making it amenable to easy review.
A restful API also has the problem that if you want fine grained auth, you'll need to remember to add the policy to each controller or endpoint, so not that different.
The typed nature of GraphQL offers a way of extending and enriching behavior of your API in a very neat, cross cutting way.
For example we recently built a filtering system that introspected over collection types at startup to generate filter input types. We then built middleware that converted filter inputs into query plans for evaluation.
I previously worked at another company that offers a public REST API for public transport. Public transport info is quite a rich interconnected data set. Despite efforts to ensure that filtering was fairly generic, there was a lot of adhoc code that needed to be written to handle filtering. The code grew exponentially more complex as more filters were added. Maybe this system could have been architected in a better way, but the nature of REST doesn't make that exactly easy to do.
Bottom line is that I feel for public APIs, that there is a lot of demand for flexibility, and eventually a public facing RESTful API will grow to match or even exceed that of a GraphQL API in complexity.
hurricaneSlider commented on It's Time to Act – A Response to Marc Andreessen blog.coryfoy.com/2020/04/... · Posted by u/wglb
This is weird, does anyone have more information on how this would happen?
Twitter allows you to import blocklists I believe. Some of these lists have been widely circulated.
hurricaneSlider commented on Show HN: DOME, a framework for making 2D games with Wren domeengine.com... · Posted by u/springogeek
You've obviously put a lot of time and effort into building and documenting this framework.
Would highly suggest adding more visuals and some way of very easily playing with runnable demos. Games are inherently audiovisual artifacts, so the lack of audiovisuals on the site is a bit of a negative signal.
Just seems fundamentally more secure.
For example we have configured our implementation of OpenID Connect to use PKCE for retrieving an authorization code, and then when calling the token endpoint, requires that the the client authenticate using a client_assertion JWT (as detailed in https://tools.ietf.org/html/rfc7523#section-2.2)