arunoda

Here we are trying to promote the idea of how you can own the AI stack & how it can help over time.

Modular synths can be very expensive, but we figured out a way to keep the cost down while keeping the sound quality high.

We sell these modules, but we also release them with a MIT license & include the schematics, PCBs, code & even how & where to source parts.

We hope to bring modular for every musician & bring the cost less than buying software plugins.

Meteor community is the best OpenSource community I have ever worked with. Unfortunately, the framework couldn't reach it's goals & we had to move on into other things :(

> Just to clarify, this is what the author wanted to do. You can create distributed apps easily using Fleek or by manually uploading to IPFS, Arweave or Filecoin.

Seems like the author has never build an app before. There nothing easy even with the current tech. It's much harder with the tech they mentioned.

Even with that, there's a centralized system anywhere. Liek Arweave's DNS system etc.

You don't need the source code to make a executable version of the Game. And it won't take 1 hour on a decent machine.

It's not traditional LOD baking. There's no LOD baking. It's the new rasterization system doing the whole work.

And most of us doesn't use fast SSDs like in PS5 and it works really well. Also these engineers said, it even works just fine with slowers HDDs too. Because, they don't stream meshes for each camera movements. But it's a continuos setup.

Did you heard about something called Next.js

This is something I did with fast.ai - https://deeplearningmantra.com/

Yes. But all of the time we poll the CDN not the production app. So, it's not like traditional polling.

This is thanks to Next.js Static Regeneration features.

Basically stale-while-revalidate header support.

Ref: https://arunoda.me/blog/what-is-nextjs-issg

The is not only GKE. But for GCE as well. I cannot create instance is almost all zones. I tried both preemptible and normal as well.

Always saying resource not available. My account is a pretty new account.

In contrast, one of my friend is having a pretty old account which is very active. He has no such issue.

So I think due to this issue, Google has enabled some resource limitation for new accounts.

But they should properly communicate this issue.

You can alias your deployment and try to add a scaling rule to the alias.

So, you don't scale up and down as you deploy. Once you call the `now alias` it'll take care of the scaling.

We don't have insight on what our customer's use mostly.

We use existing technologies. Anyone can use any cloud Database service. We've datacenters on San Fransisco and in Belgium. So, based on those users can choose where they need to deploy their DBs.

Usually we recommend to configure databases via env variables. Users can also use our [now secrets](https://zeit.co/docs/getting-started/secrets) service as well to avoid hard-coding secrets.

> something somewhat similar built from the same Dockerfile?

Yes. We build the container based on the Dockerfile.

Whether it's serverless of not choice of hardware is very important.

For an simple web app, you might not need special CPU and Memory requirements. But for a video encoding/decoding serverless app may needs different CPU/Memory requirements (and GPU).

That's what this `slot` configuration property does.

The default is good enough for all the general purpose apps. But if you need more, you can control it.

> 1. Once your docker container is built, am I paying to store it on Zeit?

No. You don't need to pay to store containers.

> 2. How is a Dockerfile versioned? Can I update it? Or do I need to redeploy

Once the Dockerfile is built, you'll get a URL for that. It's a immutable URL and you don't need to re-deploy again. It'll sleep if there are no HTTP requests. If there are it'll start again.

> 3. Is pricing for containers granular by time or per request to a container?

It's based on the container running time. But we'll have a another blog post on this soon with more info.

> 4. How can these Dockerfiles talk to each other? Is there an API or method to fetch specific url's for each container?

There's no internal API to communicate with each other. But every docker container has a URL. You can use our [alias](https://zeit.co/docs/features/aliases) feature and communicate with each other via HTTP.

I thought this is a "shipping software". But it's a music related app for Mac (Which seems to be pretty cool).

So, I am thinking this post deserves a better title.

(I work at ZEIT)

We just wanted to make "now" the go to tool for cloud deployments.

We've a backend for "now" and that's the pricing we've mentioned on our page. Just like that, we've providers for AWS, Google Cloud, Azure and etc.

We'll sure make "ZEIT now cloud backend" better everyday. But sometimes, we just wanna deploy to existing clouds. That's what this is about.

If you decide to deploy to AWS, you don't need to pay nothing for ZEIT.

You can also think like, this is we challenging ourself :)

Next.js is not a boilerplate. It's kind a mini framework comes with it's own simple Router.

Basically it makes building client side apps faster and fun. Check this for more info: https://learnnextjs.com/

As it previously said it's two different projects. Meteor is a full stack framework where it does everything from data to rendering.

But Next.js is not like this. It's only for the UI (rendering) You can build server rendered React apps pretty easily. It supports dynamic imports, prefetching, preloading and you name it.

Now you can export any Next.js app into a static app too.

Recently, Meteor adds some new JS features into it's build setup too.

I'm one of the core-contributors of Next.js. We are not anit-React or anti-spa.

And we are pretty closely work with JS stuff. But Next.js is inspired by the simplicity of PHP.

### Anti SPA

The whole idea of Next.js is to build a SPA easily. But it's also server rendered by default.

Maths.

Cool. I will create a ROADMAP.md file in the repo soon. Check it tomorrow.

Thanks for the feedback. This is the first time, I got a feedback on this.

I used it for highlighting points. I think I am over using it. Will minimize it.

Thanks.

I'd like to get you feedback on what we can improve. Could you post your feedback here - https://github.com/kadirahq/react-storybook/issues

Time time debugging is something different here. It's on working with different states of app and try to find issues.

This is a way to list components and show their different use case. We can also develop individual components by just looking at this.

Basically at the backend this is pure GraphQL. For Relay we need to have some Relay specific stuffs. That requires, more time.

In the client side too, we had to work a bit more.

That's why we go with Lokka[0]. It's just a client for any GraphQL backend. It has a simple cache.

It also supports Relay like declarative data fetching. Basically, you could build a complete app with it using Meteor's other tools like FlowRouter.

As a downside, you may need to fetch more data from the server.

As a benefit, you don't need to learn much to build a app. May be can reduce the code compared with Relay. (But that's subjective)

[0] - https://github.com/kadirahq/lokka

Okay. Kadira is a performance monitoring server for Meteor. With that, you can detect slowest parts in your app and place where it's uses a lot of server resources.

Then you can optimize accordingly. We've some guides. Start here: https://bulletproofmeteor.com/basics/what-is-performance

With GraphQL, it's possible to connect database or backend. That's the whole point here :)

There's another one I originally submitted is in this at the end. Upvote that instead :)

Falcor is based on top of REST. It's core is on top of the client side.

GraphQL is different and trying focus on the API end. (You can think it's trying to replace REST). GraphQL's client side part it Relay for now. It's somewhat complex compared with Falcor. But, I believe we can have a easy to use React independent client for GraphQL.