Exact conversation I had with support after they suspended me after I sold something for the first time, but before I mailed the item. Its like they just randomly permanently suspend people.
Try both. It may be because I've been doing Erlang so long but I still prefer it and its tools (like rebar3 and Common Test). I find the syntax more consistent, less verbose and the lack of Elixir style macros to mean less confusing third party libraries.
But I do think Elixir has its strength in web applications. The macros make Phoenix and Ecto much simpler for building full web applications and if I were building a full fledged interactive web application I'd reach for those.
So mainly personal preference, you may find Elixir preferable, but all that to simply say it is not a "strict improvement".
Oh, and one none personal preference reason: it is nice to do libraries that don't benefit from being written in Elixir (like postgrex and jason get a lot of performance out of using macros so there isn't an argument to write those in Erlang) and aren't specific to Elixir (like a Plug adapter) in Erlang so they are more easily usable across BEAM languages, a list that continues to grow.
4. The compiler should not be included and neither should the headers. Unless a user explicitly wants to include the compiler and also have a C compiler on the node in order to compile stuff on the target node there is no reason to have the header files there and relups work fine without them.
If Elixir 1.11 'mix release' still includes all of the `erts` directory then an issue should be opened.
Yeah, it doesn’t include it all the time. It’s an option, though, and one that the OP might have accidentally been using. (I think in relx there’s an explicit `include_src` flag you pass to enable it.) I was just justifying the presence of the option. It’s not always, or even usually necessary.
Not a big deal but, it was actually a bug in relx that caused it to be included (accidentally copying the erts dir from the symlink/copy in the _build/<profile>/rel/<relname>/ dir instead of from the unpacked tarball generated by systools when doing the final assembly), not `include_src`, that option only applies to the Erlang applications and not the runtime.
> Why are there 55 c-header files in the directory of the erts?
That shouldn't be the case anymore. It was a bug in rebar3 at one point and I think `mix release` may have copied said bug. If 1.11 doesn't properly not include those header files then an issue should be opened.
Curious why they suggest a reverse proxy. It may be a holdover from a time before Erlang SSL got so many improvements? Heroku moved SSL termination to Erlang from ELB's and saw great improvements, plus they released a useful lib https://github.com/heroku/snit
I suppose it could be related to their use of mochiweb still for the web layer. Maybe they'll add on HTTP/2 eventually and no longer recommend a reverse proxy.
This is an architecture I use a lot. The reverse proxy is there to implement the replication, having your application understand the replication protocol is a big ask. Instead, your app takes http requests, handles the ones it is supposed to, and forwards database requests directly to (c|p)ouchdb (after checking auth)
Right, but if your application is just a straight proxy that’s stripping out a bearer jwt or something to validate, you can’t control which documents are being synced. So you have to have 1) some understanding of the underlying protocol so you can parse the request and reject it based on user if that user does not have read/write access to the db, or 2) replicate your authorization code into couchdb with users and db permissions, at which point you have the same db per user issue (or lack thereof) plus you now have 2 user stores and 2 layers. Once this gets sufficient complexity and you try to architect something non trivial (eg. User a owns write access to document b but shares read only access to document b to user C) you end up praying to god you built the protocol parsing just right or you might accidentally let users arbitrarily write to each other’s documents.
I acknowledge that this is the same issue in a traditional dbms, but it doesn’t try to handwave away this complexity from you. It doesn’t show examples on their site about how easy replication is to set up only to be betrayed later After you’ve already integrated and marveled at the couchdb sync performance when you can’t build real permissions and would’ve been better off using Postgres and getting a bigger community and ACID/CP. and let’s be honest, almost every app is gonna need a rdbms at least for transactional data anyway (we know you’re not storing stripe billing records in your couchdb) so then the question becomes, is the sync protocol even good enough anymore to warrant using couchdb?
We really shouldn't be writing our own authentication layers (or anything security-related for that matter) unless necessary.
Case in point, this example code has a massive security issue that allows anyone to impersonate without tokens if there is an active authentication request open. Hopefully no one has used this example code to build a production system that has real user data.
This is a perfect example of why this should really be part of CouchDB/PouchDB itself and not something each person must write themselves. This should be solved once, solved right, vetted by the community, and be easy to fall into a pit of success.
I really like CouchDB and PouchDB as a product, but this insistence that this is the right path is really holding you guys back.
You're probably write about writing your own authentication layer but it still shouldn't be part of CouchDB or PouchDB. A better solution is for some OSS project to build a standard proxy that applies the document level authorization that everyone is asking for. No reason for it to be built-in.
I would agree if couchdb wasn't positioning itself as being exposed directly on the internet. If CouchDB is meant to be proxied behind another system / auth stack, then why does it have CORS support and cookie auth built in?
Both of those features are purely a client-side concern and exist because the original intent of CouchDB was real-time replication to browsers. Otherwise the proxy could do the CORS as well as the authentication and CouchDB would only require an http-level authentication pattern (like basic auth).
Having said that, I do agree that this should be compartmentalized and the end user should be able to pick and choose what features they want to allow, but I don't think that this should continue to be a separate concern that everyone is building themselves, it should be a first-party solution.
