Docker doesn't force you to put your app and your db on the same image. That is up to you. Most have "App" images and "DB" images separate.
If we want to get really specific, Its also common to see the "DB" image split up between the image of the disk where the data is actually persisted, and the image of the actual DB process. This makes it easy to play around with your data under different versions of your DB.
Would you mind expanding on what fish does out-of-the-box that prezto neglects or hides behind configuration? I am in a similar boat as you and was just wondering what I had to look forward to as a prezto user.
Well for example, with prezto I wasn't really happy with any prompt provided, so I decided to make my own, and although it's not rocket science, it's definitely easier to customize your prompt using Fish.
Another thing is writing scripts and completions functions with fish, it's a way better experience than zsh. Writing completion stuff using zsh is really painful.
The preview with the autocompletion is really cool, but maybe you can have that with zsh too.
And then there's the speed, it's totally not objective but IIRC my prezto setup was quite a bit slower.
In the end I just really appreciate that I don't have to spend time customizing my shell: now I install fish on my VMs or servers, and everything is like I want it without me doing anything.
If you're happily using prezto you may not have much to gain from using fish, and you may not even like it since there's stuff from prezto you won't find out of the box.
The biggest thing that swayed me to stick with (and optimize/customize) Prezto was the fact that most of the systems I work with have zsh, or a relatively modern version of it available in repos. Can't say the same for fish.
I can clearly see the difference between Fish and regular ol' bash, but struggling to see what value Fish adds above prezto/zsh. Could anyone help me out here?
Fish breaks compatibility with traditional shell languages. The syntax is a bit different, the variable expansion rules are a bit different, etc. It also gets rid of a bunch of features and configuration options, such history expansion ("$!!").
The positive side of this is that fish is very simple and has a very pleasant experience out of the box. And this is not just about having "good defaults" - its also about having a good design that encourages having one way to do things. That said, an interactive shell is a very personal thing. The only way to really get a good feeling is to install and check it out.
I used Fish for about of year. But I ended up recently switching back to zsh. Stock Fish is far more useful than stock zsh. However, the community around zsh is far more active and I found that most of the functionality that Fish contains and zsh lacks that there are plugins to achieve the same effects.
I'd encourage you to check it out. The scripting language in Fish is the best I've ever used for a shell. But it's also incompatible with Bash/zsh.
Agreed. Something like this but based on RethinkDB or FaunaDB would be nice to see. Also if you chose to leverage these newer databases, you could leverage their in-built PUB-SUB support instead of having to using long-polling or placing socket.io/redis ontop of the REST API.
Also, whenever I've tried to use something like this for an actual product I end up quickly outgrowing the simple CRUD model since you usually need to implement additional features ontop of the CRUD logic.
Wow I didn't know this idea was popular at all. Makes sense though.
I was trying my hand at building something similar using Go because with you can just build a binary and plop that anywhere. API-in-a-can was my end-goal.
That's exactly the problem I was trying to solve. I wanted to offload CRUD to the library, but use middleware when I need features that aren't as simple as CRUD operations.
Check out the middleware and extended usage sections for examples of how it can be extended to do things like access control and regex search.
Baucis looks neat, I'll have to dig into the docs some more.
True, but once you start adding middleware for business logic that conditionally runs for different routes, you end up with requests that get routed in a very non-linear fashion.
My experience regarding building route logic into middleware is that it starts to break down as you add more complicated logic (Real-time support, webhooks, integration with a taskqueue, etc). This is mainly because the middleware pattern works best when it performs an atomic piece of common logic for a large number of routes.
However, when you start using middleware and binding it to a specific route, for a specific collection, you quickly end up with a situation where for any given route, you can no longer look at a single function and parse the flow of logic.
Also, I find these libraries deceptively simple. They may be great for your private weekend blog, but fail to address the major pain points of API implementation in a production setting:
- Configurable and flexible access control on a per-document basis.
- Rate limiting API requests
- Mutli-node deployments
- Proper, semantic, backwards-compatible API versioning
- Realtime support (Websockets, browserchannel, long-polling, w/e you prefer)
Now I'm not saying your library needs to cover all of these pain points, but I challenge you to address all of them using a middleware-based architecture while still maintaining your sanity :)
Just my2c. The project looks great and hope you keep going with it and that I've provided some helpful feedback.
I'm hoping to implement per-document access control as middleware (you can see a first pass in 'extended usage'). Rate-limiting could be achieved through middelware like express-brute I think.
I'm also very interested in supporting websockets, but I'm not yet sure what that'd look like.
please stick with promises. Promises are the only sane way to deal with async in JS. With people starting to use async/await they become even more compelling.
The people who defend callbacks either don't understand the benefits that promises provide, don't know about async/await or are suffering from stockholm syndrome.
Callbacks do not pass the reversibility test. If everyone had started out with promises and / or async/await, and someone proposed callbacks as a way to deal with this instead, they'd be dismissed as a fool. They're an accident of history and we should forget about them as quickly as possible.
Callbacks allow await/defer in Iced CoffeeScript, not to mention the other async libs as stated above.
Promises don't really offer any benefit to program structure overall, generally devs just end up creating long chains of anonymous functions rather than long nests of anonymous functions. Promises actually discourage flat code (and functional programming) for that reason. I understand they seem attractive but become a hack in complex situations.
Oh ok, was just wondering about your reasons and that clears things up. That's a good read as well. But I think promises give you a way to compose them in a way that callbacks don't. With promises you can call easily call a function when multiple promises are fulfilled.
Actually would argue that Promises are less composable since you're forced to use whatever control flow paradigm the Promise library has provided or add another library to handle control flow.
By utilizing callbacks, you are free to use Async.js[0] or Step.js[1] to solve the problem you described. These libraries are great since they give you control over parallel vs series execution of the pre-requisite functions as well as solving more complex control-flow problems such as throttling, etc[2] (See link for more examples).
edit: Yes, you can also use similar control-flow libraries with Promises (that follow the specification) to achieve similar results but then the argument for using promises for the sake of control-flow breaks down.
At least a part of promises, the then function, is standardized through Promises/A+. This way you can easily combine different promise libraries to do things like:
- sequential execution
- parallel execution and wait for all of them to finish
Mongo is great for when you're rapidly developing a product and/or still operating at a small-medium scale.
Once you start to really scale, you'll start to find a couple parts of MongoDB break-down:
1. MongoDB has no concept of transactions and is not ACID compliant. These short-comings seem innocuous enough at first, but you end up with some crazy potential race conditions that you just end up praying you never face.
2. Distributed MongoDB layers are difficult to implement as well as maintain.
3. MongoDB Replica sets are unpredictable and unreliable in the speed at which they are able to stay up to date and require changes to your code to fully utilize (since you need to ensure you are always reading from a replica when you can, but only ever writing to the master MongoDB instance)
4. At scale, MongoDB will consistently perform worse than Postgres for CRUD-based operations
5. Do you have true relations between documents? Do you ever use Mongoose's convenient `populate()` functionality? If so, you are now making multiple db queries in series when trying to fetch a document(s) from a single collection. This starts to really hurt your query times once you get enough documents/relations in your mongo collections.
I'm sure I'm missing some, but these are some of the areas where MongoDB has fallen down for me in the past.
> Mongo is great for when you're rapidly developing a product and/or still operating at a small-medium scale.
Yesterday somebody from a node-based consultancy gave a talk at work about microservices, where he remarked in passing that they tend to start projects with mongo, then wait for a schema to kind of 'fall out' of the application as it takes shape, and then switch to postgres or something. Which doesn't seem like an awful idea.
I'm unsure if having a 'vegetarian' option is the best way to go since there are about 40 different forms of vegetarian (I have been one for 15+ years). Maybe a better approach would be the ability to exclude ingredients and groups of ingredients. To me that solves a much bigger problem that I frequently have...I have three ingredients, but don't have the one that is generally required to go along with them (ie, I have olive oil, lemon, and garlic, but am out of basil).
If I can put in that I need a recipe without basil and without a category of meat or animal products (however, honey and egg are fine), that makes this infinitely more useful. If I can save that preference, that's even better.
This looks amazing, and the StrongLoop team is chalked full of some great Node.js developers.
But for some reason I'm still worried about using it as the backbone for an enterprise scale application; it almost does too much. Perhaps I'm just too averse to this amount of "magic" in any piece of infrastructure due to my Django days.
The code is open, but you're not just buying into a single module with a single purpose -- this is an entire architecture. I guess in such cases, worry is warranted before accepted it as the backbone of your company/application.
Off-topic note on "chalked full" - you probably mean chock-full, an old phrase probably derived from the word "choke". I was entertained trying to imagine what a chalk filled team might be though :)
If we want to get really specific, Its also common to see the "DB" image split up between the image of the disk where the data is actually persisted, and the image of the actual DB process. This makes it easy to play around with your data under different versions of your DB.