Moesif Blog

Check out https://www.moesif.com, if youre interested in analytics. If you're interested in the audit logging /security angle, also check out https://apptrail.com (Disclaimer: founder).

This article could help: https://www.moesif.com/blog/technical/sdks/Best-Practices-for-Building…

Scala is definitly a cool language to learn. I like the type safety in statically typed language, and Java is just too verbose. Scala + Play Framework + Akka is solid. We use scala for parts of our pipeline for https://www.moesif.com Docker is definitly up there also with Docker Swarm/Compose, etc. Just a matter of time as Docker Cloud and the whole Container as a Service area is fully matured. I like Kubernetes on Google or Docker Swarm on Azure, but still a ways to go before it's like spinning up a Heroku like instance. They are one of the few companies able to execute very well in getting people to adopt a new technology.

Is REST perfect? Probably not. But it certainly does its job, and that's why most middle-tier APIs these days, whether it be those that power web applications or mobile apps, are in REST, with the backend itself being written in a variety of languages (PHP, Python, Java, C#, etc). I will admit that core REST doesn't support basic "querying" functionality, or even things like pagination, filtering, sorting, etc, which is why there are a set of standards, or best practices on top of REST that aim to standardize those commonly used patterns. [1] [2] [3] Finally REST, whether by design or not, follows the KISS principle (Keep It Simple and Stupid), and that's probably why it's gained as much traction as it has over the years. Want to get a user object? GET /user/<id> Want to update it? POST or PUT /user/<id> Get a list of all users? GET /user/ If you look at just the "basic" examples for GraphQL, you will understand why it's never going to replace REST in its current form. [1] Microsoft's OData: https://www.odata.org/ [2] https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filte… [3] https://stackoverflow.com/questions/207477/restful-url-design-for-sear…

Rarely does a application actually need to enable CORS. If all of your webcalls are from the same domain YOU DONT NEED CORS. (Chatbots/socket.io) You only need CORS if you need the browser to act as a middleman to pass information back. IE: Credit Card Payment IFRAME If you screw up CORS implementation it just means that anyone can read any information set by your website. https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS…

Just want to share an technical article about meltdown with things that isn't covered in the white paper. https://www.moesif.com/blog/technical/cpu-arch/What-Is-The-Actual-Vuln…

Not a book but I enjoy https://www.moesif.com/blog/

My company is actually going through the transition to cursor/keyset pagination. As a SaaS company starts having to support larger customers, they will likely have to go through this exercise. The reason is because most pagination is usually implemented with LIMIT/OFFSET in a SQL query. Using OFFSET becomes very expensive for pagination queries because the query has gotta do a full scan till it reaches the desired offset. Imagine a table with a 1 million rows, and you return pages in 100 item chunks. To get page 500, using the OFFSET method, you would have to scan through 100*499 records before you even get to the first record you care about. This can lead to all sorts of cascading problems because slow queries can cause back pressure build up from other queries queuing up. So in order to scale, services push the complexity out to the client. Conceivably, you can cache the indices on the client side, and abstract a page-number based paginator on top of it. Here's an article talking through the issue: https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filte…