Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx Unit

nginx.com

Post reply on HN
Print view View original

201–210 of 236 posts

Re: Nginx Unit

#201

Post by justinsaccount »

Matthias247 wrote: post #192
tlb wrote: post #165

Earlier quoted context omitted.

I recently switched from zeromq to straight libuv sockets with jsonl (\n-separated json) payloads. Because I'm working inside a Node process, combining zmq's threading model with Node's threading model was a pain. Now, there's a single IO thread which is the same as the Javascript engine thread, and I can use uv_work to run CPU-intensive tasks on multiple cores.

Do you not allow \n inside your JSON or encode your JSON as base64? If not you might have problems with disambiguating frame ends from line breaks inside frames. A common way for framing is to prepend each frame with it's encoded length. That's easier, faster and less error-prone than searching for ASCII delimeters.

a newline is encoded as the two characters "\n" in json and would not be confused with a literal \n (aka \x0a) character

Re: Nginx Unit

#202

Post by Waterluvian »

I hate sites like this. Im probably stupid but I have no idea what precisely it is after reading that page. I just know that marketing team wants me to believe it's going to be my saviour.

Re: Nginx Unit

#203

Post by adventist »

Waterluvian wrote: post #202

I hate sites like this. Im probably stupid but I have no idea what precisely it is after reading that page. I just know that marketing team wants me to believe it's going to be my saviour.

Yeah I had a hard time finding out what this site did.

Re: Nginx Unit

#204

Post by Whitestrake »

stanleydrew wrote: post #170
bkeroack wrote: post #164

Earlier quoted context omitted.

Secure software isn't useful? Insecure software isn't eventually value-destroying? Really what this sub-thread is arguing is that security Isn't My Job(TM) as application developer. I disagree. Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually. Not accepting unbound input and sane rate-limiting are kind of basic stuff, n…

> Secure software isn't useful? Nowhere in the sub-thread is this claimed. > Insecure software isn't eventually value-destroying? Nowhere in this sub-thread is anyone suggesting otherwise. > Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually. Nobody said this. But while we're on the topic the more likely false security bl…

> > Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually.

> Nobody said this.

That seems dishonest to say... From the grandparent:

> Or... you spend your time building something useful, leveraging skills you do have, and let nginx leverage its own strengths.

Really sounds like at least one person in this thread is advocating for app devs not to worry about things that nginx takes care of.

Agree that making straw men doesn't help. There's advice on either side regarding which one to use and realistically both are equally 'false security blankets'. The correct answer is to educate yourself on the benefit and drawbacks of each and make a conscious decision about where to implement your security.

Re: Nginx Unit

#206

Post by rspeer »

616c wrote: post #93
fermigier wrote: post #68

Earlier quoted context omitted.

Same. I really want to like (and use) uWSGI, for many reasons, but I find it's lacking severely in the department of documentation (searching "uwsgi" on Amazon gives zero hits!). A properly edited book would be awesome. I would pay for it of course.

I think their documentation is quite thorough. It's just as the other commenter indicated an app that extensible doesn't have cookie cutter simplistic configs out of the box.

It's perhaps thorough, but it's not particularly organized or edited.

Re: Nginx Unit

#207

Post by msimpson »

msimpson wrote: post #190
Xoros wrote: post #105

Earlier quoted context omitted.

I'm sorry but I'm not sure I get it. Is it like the apache mod_php for php for example ? Thanks in advance for your answer

Yes, you can generally think of it as a replacement for mod_php as Unit would parse requests from NGINX, pass them along to the PHP parser, then return the responses back to NGINX. That's the same job mod_php does for Apache and what PHP-FPM (essentially) does for servers like NGINX. You can see the PHP configuration here: http://unit.nginx.org/docs-configuration.html#php-applicatio... And here's the configuration ne…

Update:

Upon first reading I thought that Unit needed to be behind NGINX to function. When actually it listens for requests as a separate server, entirely. It only provides an API for configuration purposes.

However, If you want to use the other features of NGINX, like providing static files, you will need to put it in front of Unit.

Re: Nginx Unit

#208

Post by edgan »

derefr wrote: post #178
agentgt wrote: post #119

Earlier quoted context omitted.

Oh the "service bus" xml json is coming back... its called lambda architecture. And again nothing new except someone else takes care of some server software for you with the promise of reduced price and maintenance but the reality eventually becomes tight proprietary coupling and eventual price gauging.

Amazon's own Lambda is that, yes. But the Lambda architecture it inspired is the opposite: a de-facto standard (based on the way Amazon's works, but probably eventually an open standard) for servers any org can use to stand up their own public or private FaaS cloud, which developers can deploy Lambda functions onto rather than having to build an entire container/VM just to slot it into OpenStack.

I doubt it will ever be a standard. Amazon loves vendor lock in. Plus most of the cloud services love to do their own thing for each service type. The main exception seems to be Kubernetes. Google has it in GCE, and Amazon has said they are working on their own Kubernetes service. If that happens, I bet Azure will follow if they aren't already working on it.

Re: Nginx Unit

#209

Post by [deleted] »

AgentME wrote: post #200
Matthias247 wrote: post #192

Earlier quoted context omitted.

Do you not allow \n inside your JSON or encode your JSON as base64? If not you might have problems with disambiguating frame ends from line breaks inside frames. A common way for framing is to prepend each frame with it's encoded length. That's easier, faster and less error-prone than searching for ASCII delimeters.

If you do the JSON serialization yourself, there's no reason for newlines to be in the JSON. (Newlines within strings are encoded as \n.)

[deleted]

Re: Nginx Unit

#210

Post by derefr »

edgan wrote: post #208
derefr wrote: post #178

Earlier quoted context omitted.

Amazon's own Lambda is that, yes. But the Lambda architecture it inspired is the opposite: a de-facto standard (based on the way Amazon's works, but probably eventually an open standard) for servers any org can use to stand up their own public or private FaaS cloud, which developers can deploy Lambda functions onto rather than having to build an entire container/VM just to slot it into OpenStack.

I doubt it will ever be a standard. Amazon loves vendor lock in. Plus most of the cloud services love to do their own thing for each service type. The main exception seems to be Kubernetes. Google has it in GCE, and Amazon has said they are working on their own Kubernetes service. If that happens, I bet Azure will follow if they aren't already working on it.

I (and others) are not so much imagining a standard between cloud vendors, as we're imagining a standard "FaaS server function API" (sort of like how the web has a standard DOM API) supported by several FOSS FaaS server implementations (sort of like how the web has several FOSS Javascript engines.)

Given such a standard API and compatible servers, you'd then deploy a FaaS server cluster to your public/private cloud of choice, the same way you deploy e.g. a Kubernetes cluster, or a Riak cluster.

There would likely by small public clouds attempting to be "FaaS native" by exposing only such servers in a multitenant configuration (like small public clouds like Hyper are currently doing with CaaS.) Their implementations wouldn't always be exactly compatible, and might have some lock-in.

However, once FaaS "caught on" with the enterprise, a FaaS server would likely make its way into the OpenStack architecture.

At that point, you'd see medium-sized public cloud providers like OVH and DigitalOcean set up their own multitenant FaaS clusters as well, probably with custom code, but built to be compatible with the OpenStack FaaS tooling, to allow enterprises the freedom to move FaaS functions freely between public and private clouds.

And, eventually, the other major cloud providers would feel the need to support the API.

---

This path has already been followed: it's what happened to Amazon S3—first cloned (but not compatibly) in FOSS by tools like Riak CS; then standardized by OpenStack Swift; then cloned compatibly in FOSS by tools like Minio; then picked up by medium-scale clouds like Rackspace; and then, eventually, picked up by Azure and GCP as secondary APIs to address their equivalent offerings (that originally had quite different APIs.)

Post reply on HN