Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have an application that we implemented kind of a microservices type architecture. The application contains 6 services (6 Docker containers). I need to load test this application. As I don't have much experience in the testing field, I'm not sure which method to use.
Right now, I have used the Gatling Load testing application for the load test. Here, I record the testing script by start the recorder and wander around my application to record all routes. I have gone through most of the routes in that single recording in order to mimic a practical user. I thought, normally users use an application like this and I can load test with its 1000 times by editing the number of threads/users.
Later I read about API testing which we will focus on APIs. Loading each APIs with a heavy load. So, I'm confused that which testing method should I use? If we go for API testing, it will provide only how much we can scale for that particular API right? (Not sure)
Is there any issue with my method of load testing?
It depends entirely on what you hope to achieve...
If you're looking to validate that your entire application (code + production infrastructure) can handle a given load, then driving as though going through the full website is the right path.
However, if you're looking to see how a particular api scales or want to help developers explore the ramifications of changes, then you will probably want to just drive that API directly to avoid other limitations your system may have.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 months ago.
The community reviewed whether to reopen this question 9 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
In nextjs u can write API routes using the api named directory inside the pages directory, thus i was wondering if i can write all of my server code(api endpoint,database queries...ect) inside of NextJS instead of having an actual nodejs app running elsewhere?
The short answer: Yes. Nextjs is in fact an Nodejs app itself.
The long answer:
Depending on your apps usage and scale and the size of your team there are some nuances to consider.
If you use Nextjs for both Server-side Rendering (SSR) and handling api calls, it will effectively have two responsibilities.
This is perfect for small teams because the stack is relatively uncomplicated and all in the same repository (and module).
At a certain scale you might want to optimise deployments to gear towards either rendering or handling api calls. It might become difficult to keep both extremely highly performing - at which point a separate, specialised, backend might become relevant.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
This question is not related to code or any bug. I have an organisation related query. I am a front end developer. I consume web API's developed by the back end developers in my company. The problem here is, they share it via postman. API's are segregated project wise in folders. Problem is, the nomenclature of the API as well as the functionality differs. This creates lot of confusion for me while consuming API's. secondly, There is no indication that whether the API is deployed on a server or not. So sometimes, I end up writing the code and realize that the specific API is not deployed yet.
My question is, how does the world do it? How is the communication between developers established with this specific domain? How can one overcome this problem?
I hope i interpret your question correctly:
One of the methods used in the industry is scrum (specifically daily stand ups) where you talk about the work you intend to perform that day. This will give the back-end guys an opportunity to tell you its not yet ready. It really depends on the culture in the company. Why are they writing endpoints not yet deployed, and if not deployed, how difficult is it for you to make them deploy them?
Another way is DevOps which many think of as scrum for the entire value chain.
These methologies are however not something you can dictate, but they arose because of the problem you are refering to.
In practice: You should probably ask to get another folder called "SafeToUse" or "ReadyForConsumption" in Postman and in this way you can clearly see whats on its way and whats ready.
I hope this answers your question. I can't recommend anything more specific not knowing the kind of work you perform - normally in my experience the front- and backend for a given project is developed with close communication.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've got a web app where I use plain file system for my custom logs - a lot of small files, I don't want to put that into db, that works for me quite well. But now I need to scale my app by using a load balancer in front, so I also need to keep those logs in sync between servers. Is there any reliable solution for such cases ? I know I could sync it by some OS means, or by scripting, but I'm thinking if there is any better solution for such scenarios? Is it the case for MongoDB usage or something more modern or is it better to keep it on file system as plain files ?
This questions is going to get you some heat since essentially your asking for our opinion. Ill be frank tho and wont argue with anyone since its just MY opinion. With web apps in my humble opinion, its always better to keep your data in a DB for scalability but also for analytical research. I know little about what your app does but its easier to write third party data apps that tell you how many of X or Y etc when its centrally stored in a DB. Since the app that gets said data can be anywhere. I know I probably wasted time with an argument but hey, hope I helped a bit.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
At the risk of this question being closed I will ask anyway.
I have been looking at the different JavaScript Frameworks as most jobs roles seem to want:
angular.js
Knockout.js
Node.js
Whilst i can see Angualr.js and Knockout.js provides a MVC construct to the markup pages (though still not sure which one is best to use) I cannot see what is the case for node.js?
Whilst I appreciate node.js is good for real-time comms but so is Signalr as they both use long-polling.
At present I use signalr to update images on my clients.
is there any purpose to swapping this out for node.js?
Like I said this question could be voted to be closed as it may seem to be asking an opinion - and that would be an answer to me in itself as it would be down to developer choice but is there a DEFINITIVE reason to use node.js over signalr?
thanks
One reason to use node.js is code redundancy. Both the server and client run the same language, thus they may share a certain part of the codebase, meaning potentially less to write. With libraries like Browserify this process can be made a lot more transparent and writing the client-side can be almost indistinguishable from server-side development. Another opportunity this opens up is both client and server side rendering + MVC setups with, for example, rendr.js. So you can have both the fast load speeds of server-side and responsiveness of client-side rendering. If any of this will be useful naturally depends on what you are developing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
This is not a holy war question, I'm just asking what framework would be the best choice in terms of performance in my specific project.
I'm writing a REST API and choosing between Node.js and Sinatra. One method of the API will be used very frequently (± 100k requests per day).
This request is very simple: select one row from a database, make a few calculations, update one row in a database.
But, as I said, it will be called frequently and I need to choose a framework that will perform better in this case.
This is a simple app and in this case I don't care which framework is easier or "better", just interested in the performance. I already wrote a prototype in Sinatra, the whole app is less than 150 lines of code.
I read about Node.js, but never created a real app with it.
Will Node.js be a significantly better choice for this project in terms of performance and scalability?
100k requests a day is roughly a request per second assuming a flat distribution of requests during the day. Both solutions will probably serve that without a problem. You're probably falling into the premature optimisation trap.
That being said, Javascript, because of it's asynchronous nature is significantly better at high i/o than Ruby (Sinatra is just a simple web framework, Node is just how you run Javascript on a server).
Now as per the "what should I do", I suspect most people would tell you to use the prototype you already have working and use it until it's no longer good, if it ever comes to it. Seeing it's such a small app it shouldn't be a problem to rewrite it later with Node anyway!