starptech

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.

I bought it from a re-seller. On ThinkPad Germany it is also sold out.

Thinkpad T14 Gen2 is shipped with (14") 4K UHD (3.840 x 2.160), IPS with Dolby Vision™, 500 cd/m² and Ryzen 5850U. Linux certified.

We are delighted to go down this road with the community. Feel free to ask any questions.

Exactly! I use https://github.com/StarpTech/k-andy for most projects with a limited budget.

Your setup is unrealistic. 100 million requests per month with 80 concurrent requests?. 1000 $ is cheap if you try to run wikipedia.com fully managed.

... and why have you left stripe ??? :/

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!

Check at first the quality of your chair and the height. https://www.quora.com/What-is-the-standard-office-chair-heig... if you have still the issue contact a doctor.

Then it takes its necessary time. Why it's a bottleneck? They don't work fulltime on it?

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.

The problems reminds me of https://github.com/hueniverse/oz/ it's from one of the former oauth guys.

I really like https://www.atlassian.com/git/tutorials/what-is-version-cont.... It starts with the fundamentals and goes deeper one by one.

Generating PDF's from HTML and Web Technologies is nothing new. There are tons of PHP and Node.js libs e.g I could host a service in minutes with the help of https://github.com/GoogleChrome/puppeteer in only few lines of code. Hosting that service on digital-ocean would reduce the cost to ~5/month. Cheers!

Why do you have that feeling? https://www.meteor.com/ or https://www.meteor.com/showcase

By the way: https://www.reddit.com/r/javascript/comments/672nrk/is_meteo... the second comment ;)

What're the reasons why it should be dead? Development is very active https://github.com/meteor/meteor/releases and roadmap are up-to-date https://github.com/meteor/meteor/blob/devel/Roadmap.md. What're your requirements? Meteor can solve your problems but can also be too much.

From a technical perspective, a tracing system like opentracing is essential. Jaeger is a very user-friendly and great standard to do it. I prefer it over Zipkin.

If you want to maintain an "index" you can use a service-discovery service like https://www.consul.io/ and build tools on it.

Here you can see an example how to manage it with hemera in the node.js world https://github.com/hemerajs/aither. We use a production-grade messaging system called https://nats.io as service-discovery and transport layer and have a very transparent and maintainable landscape of our services.

That's correct but I'm looking it from a completely different angle. Many projects starting with a responsive web app to support desktop and mobile users at once. When the integration isn't great they will use a shell like Electron or PhoneGap so far from a web-based background. The reasons for this are clear:

- Same technology - Reuse all or many code - Frontend people are easier to hire and cheaper

To have a win-win situation. Most projects are starting with a web project and are expanded to desktop and mobile. If you can reuse your code, technology without any big impacts in performance or UX you will win in any aspect.

Not interested cause relocation but want to introduce https://github.com/hemerajs/hemera

Warning self-promotion: https://github.com/hemerajs/hemera