Competition is good, but Fly.io has proven problematic based on my two years of production experience. Anyone requiring reliability, professional support should avoid using services with significantly less experience than their competitors, such as S3, Cloud Buckets, and R2. Personally, I do not trust any service that relies on Fly.io. This perspective may change, but so far, they have proven to be an unreliable partner.
Hm, that's not available on Lenovo's UK store that I can find :(
Maybe it's also a regional issue.
edit: or the US store? shows me a T14 Gen 2 (AMD) - Up to AMD Ryzen™ 7 Pro 5850U Processor, Up to 14.0" FHD (1920 x 1080) IPS, anti-glare, touchscreen with Privacy Guard
or
T14 Gen2 (Intel) -
Up to 11th Gen Intel® Core™ i7-1185G7 with vPro™,
Up to 14" UHD (3840 x 2160) IPS, anti-glare with Dolby Vision™
https://github.com/StarpTech/k-andy : "Zero friction Kubernetes stack on Hetzner Cloud", basically specialized k3s with some pieces customized for Hetzner, and automatic deployment on Hetzner cloud instances.
A lot of web stacks optimize for concurrency. Based on 2GB memory, which ends up being ~25MB per request (which for me is extremely high), I don't see it as being unrealistic. Especially for the use case I'm considering. Typically the only reason these boxes exist is to allow a web browser to gain access to data in a database, so most of the 1000ms per request wouldn't be spent in CPU, it will be spent waiting for the database to return a response.
Stay away from Orientdb it is a super hyped multi-model database but it's unreliable and hard to maintain. I worked with it for 2 years incl. paid professional support.
The chapters reads like the Apollo documentation. Does the book contains real world experience of topics like caching, CDN's, REST integration, deduplication of requests? Thanks for sharing this with the community!
There are 4 applications the readers of this book are going to build along the way. I think that's more pragmatic than other programming books.
Most, not all, of the other mentioned topics are too niche to address them in a beginners GraphQL book that should be read by a broader audience IMO. But I keep these topics in a list to write supplementary blog posts about them.
Thanks for your insights on this! Helps a lot to identify the pain points the community has on this topic :)
I think you have to explain the purpose of the "shared" team. From my understanding, they should ensure quality and stability. In that case, you have to hire more people to speed up this process or when possible try to automate such tests.
In the other case, you could remove the "public API routes/contracts shared project" and replace it with a proxy like https://konghq.com/kong-community-edition/ which provides better integration options. Imagine each team could deploy multiple microservices without to integrate all endpoints on a shared repository because at deploy time you only have to send the service configuration to Kong and it will route every incoming request with the specified public DNS to the associated target URL.
You could maintain a config file per service (like travis.yml) and use it to configure Kong once when your project is deployed. https://github.com/mybuilder/kongfig
Kong is very interesting because you can centralize Authentication, Logging, Metrics, Traffic for all your services.
