5 ms·

> Does this mean that you can hack some database storage (w/ sqlite) together on frontend only hosting platforms like Github or Netlify? You can run SQLlite i

by aikah 7y ago

> Does this mean that you can hack some database storage (w/ sqlite) together on frontend only hosting platforms like Github or Netlify? You can run SQLlite in the client via webassembly therefore open a SQLite file in the browser to query it yes, you just can't write anything in it and expect it to persist somehow on the static hosting service itself. > The best I came up with: let's say you have a toy project, and you call the Github API and replace the file upon every write. Implementing a read is easier as you know where the file is located. This hack shows that you somehow need write access to get any form of performance out of it, because this hack is super slow. No you'll need a server for that, you can't make random HTTP requests to any server in the browser, because of CORS/SAME ORIGIN policies. "SQLite is serverless" is meaningless buzzword. It just means that SQLite is equivalent a flat file where you'd shove some data, just that you can use SQL to query that file instead of having to index data in it yourself.

giancarlostoro 7y ago
You could make it persist if you have it uploaded somewhere. But then I guess thats not serverless.
- Frost1x 7y ago
  "Serverless" is a garbage marketing term in general. It sounds sexy to nontechnical management folks who are used to hearing a bunch of expensive costs and the word "server" associated with them in some fashion. From that view, anything that gets rid of those pesky "servers" sounds like a win.
  - giancarlostoro 7y ago
    It is, I did Azure Functions which is their "serverless" solution. It's either a type of CGI 'trigger' which is not as impressive however, another 'function' can be triggered based on Database actions or file uploads in their Blob Storage. So it's just handy if you're all in on Azure, and probably other clouds because you can have code run immediately when events happen for certain services. Outside of that, I find it wasteful. The other buzzword is microservices. I was working a gig that involved running like 10 on a MBP with 16GB of RAM and it froze up the laptop. Java is not a language for micro anything, at least not in regards to memory. Was fun but dreadful to work with more than 3 local services at once. The creators of the framework suggested to mock services, but it was just messy to do that too.
    - pm90 7y ago
      > The other buzzword is microservices. I was working a gig that involved running like 10 on a MBP with 16GB of RAM and it froze up the laptop. Java is not a language for micro anything, at least not in regards to memory. Was fun but dreadful to work with more than 3 local services at once. The creators of the framework suggested to mock services, but it was just messy to do that too. This seems like a strange criticism. It appears that you want a full deployment of the platform on your local machine. But Microservices aren’t optimized to run on your local machine; they’re meant to be deployed to kubernetes/docker swarm/mesosphere. I’m also no fan of Java but I don’t think it’s the language that is preventing you here? All speculation since I don’t know the details but it sounds suspiciously like the JVM is getting stuck trying to allocate heap during startup (this is just a guess).
      - tracker1 7y ago
        And when you need to interact with other services in a disconnected way? You have to run them somewhere... and local should generally be an option, even if that's to a local single-node (mini)kube cluster. There's nothing wrong with needing to run more than one thing while developing/testing and interacting. There are other options, but it's not a clearly bad approach. That said, I would definitely lean towards Go or Rust myself if given the option (even though I have limited exposure to either) over Java. C#/.Net Core is in the middle imho. Even node works pretty well, but the tons of files thing bugs me sometimes. We're leveraging more node and C# where I work and I definitely prefer node... but for more services I do think that Go and Rust are probably better options.
        pm90 7y ago
        In general, staging environments are the solution to cross service testing for Microservices. The expectation that a Microservice must be testable end to end locally is not one I would like to encourage. The whole point of splitting out a service this way is that individual services have very narrowly scoped, independent function and can be tested on their own, perhaps with mocked data. One wouldn’t expect to run all of a companys entire pipeline locally on a single laptop. Expecting that for Microservices is similar.
  - jtms 7y ago
    This is overly reductive. “Serverless” might be overhyped, but amongst devs and ops it is a perfectly good way to succinctly describe a very specific architecture with real merit. Paying for exactly the compute time i use is pretty sexy to me when I want to deploy and scale a side project.
    - giancarlostoro 7y ago
      Agreed, I'm not big in devops, but I can see the usefulness of it if you're already part of a cloud provider, but like I said I only know of the capabilities of it in Azure, I'm not familiar with the capabilities elsewhere.
    - Frost1x 7y ago
      What was wrong with "managed"? It's pretty generic and transfers across many domains and also, more fairly descriptive of what's going on.
      - jtms 7y ago
        "managed" is an AWS instance or a digital ocean droplet. "serverless" is an entirely different thing.
        Frost1x 7y ago
        "Serverless" is another level of abstraction and management, that's it. Are you proposing that a term collision adds too much confusion? "Managed" hosting has been around for decades as have "managed" services, in general, long before Amazon even existed. EC2 brought a new level/layer of automation and management ontop of what colo datacenters used to do, provide scaling etc. To be clear I'm not saying it's simple but "managed" describes much of it.
        jtms 7y ago
        I would argue that the architectural implications of using a "run individual functions on a remote pool of computing resources and build your client application around this pattern and only pay for the exact amount of compute time you use" is not sufficiently covered by the term "managed". I think there could have perhaps been a better name than "serverless" chosen, but that's the name enough people have agreed on to use when talking about this specific architecture that it would be difficult to use another one.
  - pm90 7y ago
    Not true. While the term is hyped, it is done so for good reasons. It’s not just that management doesn’t want the pesky servers, it’s that most developers themselves don’t want or care for it. Devs want to use platforms that let them quickly deploy their code that implements business logic, and servers/kubernetes and other abstractions aren’t things many devs give a fuck about.
  - wyago 7y ago
    This perspective has always confused me. Would you say that structured programming was a garbage marketing term, since even though the programming language didn't have goto the compiled machine code has jumps and branches? I would hope not, because the point is that an interface is provided on top of the underlying structure so that you don't have to think about gotos outside of exceptional cases. Not having to think about what servers in which datacenter are serving a request is pretty convenient. We can argue about whether the pricing for most serverless computing is bad, but as far as the term and the technology itself I don't see how this is different from any other abstraction.
    - Frost1x 7y ago
      The criticism is on the nomenclature, not what's being provided. "Structured programming" is... pretty well named IMHO. Serverless is a misnomer at best and borders on fraud/false advertising from the name alone. The technologies are fine and there are potentially useful cases for it. It's no silver bullet though and is overhyped IMHO.
- ComputerGuru 7y ago
  I’ve done that, by persisting to an S3 backend.. but there’s no concurrent access and it is all one big race condition.
filleduchaos 7y ago
"SQLite is serverless" is by no means a meaningless buzzword. The term had a clear meaning before it was coopted by the current web dev fad. SQLite does not operate on a client-server architecture the way e.g. MySQL or PostgreSQL do.
- mrmekon 7y ago
  Just to back that up, it had a clear meaning because -less is a valid suffix to append to English words. When grandma runs out of cookies she is cookieless (when a website doesn't use cookies it is also cookieless). It doesn't have to be "in the dictionary" to make sense in conversation. A quick search of usenet shows "serverless" being used in 1994. It wasn't a term or a buzzword, it wasn't common, it was just English: https://groups.google.com/d/msg/comp.os.linux.misc/r76oNl98C1k/CkuR8EEuYV0J https://groups.google.com/d/msg/comp.os.linux.misc/r76oNl98C...
  - filleduchaos 7y ago
    Yes, this is what I was trying to say. It wasn't a thing people would throw around like a buzzword but if someone used it in conversation and especially in context (like the SQLite page, which was written over a decade ago, does) people would understand what you meant.
- qes 7y ago
  > does not operate on a client-server architecture That was never a common usage of the term serverless.
  - filleduchaos 7y ago
    The linked article was written in 2007, for your information. Software development didn't begin or end with web dev and the cloud.

by aikah 7y ago

giancarlostoro 7y ago

You could make it persist if you have it uploaded somewhere. But then I guess thats not serverless.

Frost1x 7y ago
"Serverless" is a garbage marketing term in general. It sounds sexy to nontechnical management folks who are used to hearing a bunch of expensive costs and the word "server" associated with them in some fashion. From that view, anything that gets rid of those pesky "servers" sounds like a win.
- giancarlostoro 7y ago
  It is, I did Azure Functions which is their "serverless" solution. It's either a type of CGI 'trigger' which is not as impressive however, another 'function' can be triggered based on Database actions or file uploads in their Blob Storage. So it's just handy if you're all in on Azure, and probably other clouds because you can have code run immediately when events happen for certain services. Outside of that, I find it wasteful. The other buzzword is microservices. I was working a gig that involved running like 10 on a MBP with 16GB of RAM and it froze up the laptop. Java is not a language for micro anything, at least not in regards to memory. Was fun but dreadful to work with more than 3 local services at once. The creators of the framework suggested to mock services, but it was just messy to do that too.
  - pm90 7y ago
    > The other buzzword is microservices. I was working a gig that involved running like 10 on a MBP with 16GB of RAM and it froze up the laptop. Java is not a language for micro anything, at least not in regards to memory. Was fun but dreadful to work with more than 3 local services at once. The creators of the framework suggested to mock services, but it was just messy to do that too. This seems like a strange criticism. It appears that you want a full deployment of the platform on your local machine. But Microservices aren’t optimized to run on your local machine; they’re meant to be deployed to kubernetes/docker swarm/mesosphere. I’m also no fan of Java but I don’t think it’s the language that is preventing you here? All speculation since I don’t know the details but it sounds suspiciously like the JVM is getting stuck trying to allocate heap during startup (this is just a guess).
    - tracker1 7y ago
      And when you need to interact with other services in a disconnected way? You have to run them somewhere... and local should generally be an option, even if that's to a local single-node (mini)kube cluster. There's nothing wrong with needing to run more than one thing while developing/testing and interacting. There are other options, but it's not a clearly bad approach. That said, I would definitely lean towards Go or Rust myself if given the option (even though I have limited exposure to either) over Java. C#/.Net Core is in the middle imho. Even node works pretty well, but the tons of files thing bugs me sometimes. We're leveraging more node and C# where I work and I definitely prefer node... but for more services I do think that Go and Rust are probably better options.
      - pm90 7y ago
        In general, staging environments are the solution to cross service testing for Microservices. The expectation that a Microservice must be testable end to end locally is not one I would like to encourage. The whole point of splitting out a service this way is that individual services have very narrowly scoped, independent function and can be tested on their own, perhaps with mocked data. One wouldn’t expect to run all of a companys entire pipeline locally on a single laptop. Expecting that for Microservices is similar.
- jtms 7y ago
  This is overly reductive. “Serverless” might be overhyped, but amongst devs and ops it is a perfectly good way to succinctly describe a very specific architecture with real merit. Paying for exactly the compute time i use is pretty sexy to me when I want to deploy and scale a side project.
  - giancarlostoro 7y ago
    Agreed, I'm not big in devops, but I can see the usefulness of it if you're already part of a cloud provider, but like I said I only know of the capabilities of it in Azure, I'm not familiar with the capabilities elsewhere.
  - Frost1x 7y ago
    What was wrong with "managed"? It's pretty generic and transfers across many domains and also, more fairly descriptive of what's going on.
    - jtms 7y ago
      "managed" is an AWS instance or a digital ocean droplet. "serverless" is an entirely different thing.
      - Frost1x 7y ago
        "Serverless" is another level of abstraction and management, that's it. Are you proposing that a term collision adds too much confusion? "Managed" hosting has been around for decades as have "managed" services, in general, long before Amazon even existed. EC2 brought a new level/layer of automation and management ontop of what colo datacenters used to do, provide scaling etc. To be clear I'm not saying it's simple but "managed" describes much of it.
        jtms 7y ago
        I would argue that the architectural implications of using a "run individual functions on a remote pool of computing resources and build your client application around this pattern and only pay for the exact amount of compute time you use" is not sufficiently covered by the term "managed". I think there could have perhaps been a better name than "serverless" chosen, but that's the name enough people have agreed on to use when talking about this specific architecture that it would be difficult to use another one.
- pm90 7y ago
  Not true. While the term is hyped, it is done so for good reasons. It’s not just that management doesn’t want the pesky servers, it’s that most developers themselves don’t want or care for it. Devs want to use platforms that let them quickly deploy their code that implements business logic, and servers/kubernetes and other abstractions aren’t things many devs give a fuck about.
- wyago 7y ago
  This perspective has always confused me. Would you say that structured programming was a garbage marketing term, since even though the programming language didn't have goto the compiled machine code has jumps and branches? I would hope not, because the point is that an interface is provided on top of the underlying structure so that you don't have to think about gotos outside of exceptional cases. Not having to think about what servers in which datacenter are serving a request is pretty convenient. We can argue about whether the pricing for most serverless computing is bad, but as far as the term and the technology itself I don't see how this is different from any other abstraction.
  - Frost1x 7y ago
    The criticism is on the nomenclature, not what's being provided. "Structured programming" is... pretty well named IMHO. Serverless is a misnomer at best and borders on fraud/false advertising from the name alone. The technologies are fine and there are potentially useful cases for it. It's no silver bullet though and is overhyped IMHO.
ComputerGuru 7y ago
I’ve done that, by persisting to an S3 backend.. but there’s no concurrent access and it is all one big race condition.

filleduchaos 7y ago

"SQLite is serverless" is by no means a meaningless buzzword. The term had a clear meaning before it was coopted by the current web dev fad. SQLite does not operate on a client-server architecture the way e.g. MySQL or PostgreSQL do.

mrmekon 7y ago
Just to back that up, it had a clear meaning because -less is a valid suffix to append to English words. When grandma runs out of cookies she is cookieless (when a website doesn't use cookies it is also cookieless). It doesn't have to be "in the dictionary" to make sense in conversation. A quick search of usenet shows "serverless" being used in 1994. It wasn't a term or a buzzword, it wasn't common, it was just English: https://groups.google.com/d/msg/comp.os.linux.misc/r76oNl98C1k/CkuR8EEuYV0J https://groups.google.com/d/msg/comp.os.linux.misc/r76oNl98C...
- filleduchaos 7y ago
  Yes, this is what I was trying to say. It wasn't a thing people would throw around like a buzzword but if someone used it in conversation and especially in context (like the SQLite page, which was written over a decade ago, does) people would understand what you meant.
qes 7y ago
> does not operate on a client-server architecture That was never a common usage of the term serverless.
- filleduchaos 7y ago
  The linked article was written in 2007, for your information. Software development didn't begin or end with web dev and the cloud.