3 ms·

If you're tired of writing HTML that isn't inside Javascript. Seriously, though -- the company I'm working for is serving SPAs that interact with APIs directly

by zck 9y ago

If you're tired of writing HTML that isn't inside Javascript. Seriously, though -- the company I'm working for is serving SPAs that interact with APIs directly, so you can serve everything except your API from a CDN. You don't need a server to render your pages, and perform your API actions; you can just use a SPA. I'm not super knowledgeable about all this frontend stuff, so I can't really speak to if it's the only option, but it does seem like one thing that's pretty unique.

applecrazy 9y ago
Doesn't that run into the issue of exposing all your business logic in the JavaScript? Somebody can also build a malicious client to query your internal APIs, maybe even leak some data? I want to know because I was thinking of doing this in a side project, but I fear my proprietary functionality could be exposed.
- Kpourdeilami 9y ago
  You can expose your business logic as an API endpoint and have your single-page app make a request to it. For example, say you have a bunch of invoices that you can access by making a GET request to /invoices/ ``` { "count": 1, "results": {...} } ``` Then if you want to perform an action on a particular invoice, you can access it using the /invoices/:invoice_id/action endpoint. For example, let's say you want to pay the invoice with id=1, then all you have to do is make a POST request to /invoices/1/pay/ and if you want to pass variables to your action, you can do it through the body of the request. For example, if you want to pay your invoice with a card on the account with id=4, all you have to do would be to make a POST request to /invoices/1/pay/ with the following body: ``` { "card_id": 4 } ```
- noodle 9y ago
  Some will have to be in the JS, but that isn't really any different from non-SPA web apps. They still serve up JS files that have business logic. JS and business logic are, to some degree, inseparable. If you're giving trust to a user to query the API, they could also maliciously leak data or execute queries inside a normal web app just as easily if you build something appropriately secure.
  - imhoguy 9y ago
    This is about separation of layers and defined interface contracts which applies both to SPA and traditional server-side rendered pages. Remember mangling with query params back in the time? `.php?param=...`. Now regarding "JS business logic" in SPA, I think it should be only presentation logic (formating, handling input, navigation etc.) and at most some data aggregation from various sources. It needs some real architecting skills to build secure and limited API. Unfortunately often ease is prefered over security for some so I have witnesed Elasticsearch or MongoDB APIs exposed to SPAs without any additional layer.
Eridrus 9y ago
Wrote an SPA recently with Polymer + Firebase. Besides the learning curve, it's actually kind of nice not to need a backend if you can get away with it.

by zck 9y ago

applecrazy 9y ago

Doesn't that run into the issue of exposing all your business logic in the JavaScript? Somebody can also build a malicious client to query your internal APIs, maybe even leak some data? I want to know because I was thinking of doing this in a side project, but I fear my proprietary functionality could be exposed.

Kpourdeilami 9y ago
You can expose your business logic as an API endpoint and have your single-page app make a request to it. For example, say you have a bunch of invoices that you can access by making a GET request to /invoices/ ``` { "count": 1, "results": {...} } ``` Then if you want to perform an action on a particular invoice, you can access it using the /invoices/:invoice_id/action endpoint. For example, let's say you want to pay the invoice with id=1, then all you have to do is make a POST request to /invoices/1/pay/ and if you want to pass variables to your action, you can do it through the body of the request. For example, if you want to pay your invoice with a card on the account with id=4, all you have to do would be to make a POST request to /invoices/1/pay/ with the following body: ``` { "card_id": 4 } ```
noodle 9y ago
Some will have to be in the JS, but that isn't really any different from non-SPA web apps. They still serve up JS files that have business logic. JS and business logic are, to some degree, inseparable. If you're giving trust to a user to query the API, they could also maliciously leak data or execute queries inside a normal web app just as easily if you build something appropriately secure.
- imhoguy 9y ago
  This is about separation of layers and defined interface contracts which applies both to SPA and traditional server-side rendered pages. Remember mangling with query params back in the time? `.php?param=...`. Now regarding "JS business logic" in SPA, I think it should be only presentation logic (formating, handling input, navigation etc.) and at most some data aggregation from various sources. It needs some real architecting skills to build secure and limited API. Unfortunately often ease is prefered over security for some so I have witnesed Elasticsearch or MongoDB APIs exposed to SPAs without any additional layer.

Eridrus 9y ago

Wrote an SPA recently with Polymer + Firebase. Besides the learning curve, it's actually kind of nice not to need a backend if you can get away with it.