I have created a web application that will have to operate under a heavy client load, so I was planning to test it out with automated services, yet I don't seem to be able to find any. In essence, I am looking for a way to imitate real requests from various locations to my server. WebPageTest seems to do the job, but I can only run it once. Is there a way I can automate it to run every so many seconds?
TIA
There is a WebPageTest API (https://github.com/WPO-Foundation/webpagetest-docs/blob/master/dev/api.md) which you could use to automate these requests using a CRON job.
There are also off-the-shelf solutions that do this, such as SpeedCurve (paid service).
Related
Background:
I'm building an API service app. The app is just like any other, you send an HTTP request and receive a response. This seems simple up until I start thinking about user registration, payments, authentication, logging and so on.
Application:
tl;dr simple app diagram
Endpoints listening for HTTP requests and doing all the request related work. This is the core of the service, what the service user would use this app for. Directly not accessible to the end user (unless somehow it knows the url). Python flask server, deployed on google cloud RUN.
API gateway acting like a proxy and a single access point forwarding the requests to the endpoints. This is the service access point for the end users. This part will also be responsible for authentication, limitations, logging and tracking the use of the API endpoints. Python flask server, deployed on google cloud RUN.
Website including documentation, demo and show off of API calls through API gateway, registration, payment (thinking of Stripe) etc. VueJS app on NodeJS server on google cloud compute VM.
Database storing credentials of registered users, payment information and auth keys. Not implemented yet.
Problems:
Is this architecture proper? What could be done differently or improved? How could I further simplify all the interactions between separate parts of the app? Am I not missing any essential parts?
Haven't yet implemented the database part and I'm not sure what should I
use? There are plenty of options on google cloud. Also I could go with something simple and just install a DB with http/JSON interface on google cloud compute VM. How do I chose the DB? Given such an app, what would be the best choice?
Please recommend literature/blogs/other sources of info on similar app
architecture for new developers not familiar with it?
This is pretty open ended, but here are some general comments:
Think about how your UI will work. Are you setting up a static app served directly from cloud storage or do you need something rendered on the server? Personally I prefer separating UI from API when I can but you need to be aware of things like search engine optimization. Even if you need to render some content dynamically your site can still be static. Take a look at static site generators like Gatsby. I haven't had to implement a server rendered UI in years and that makes me happy.
API gateway might be fine, but you don't really need it for anything. It might be simpler to start without it and concentrate on what actually matters. If your APIs are being called by an external client you can't trust the calls anyways and any API key you might be using will be exposed. I'd say don't worry about it for a single app. That being said, if you definitely want to use a GW then use one, just be aware that it is mostly a glorified proxy and not some core part of your architecture.
Make sure your API implementations don't store any local state so you can rely on Cloud Run scaling your services up and down. Definitely don't ever store state directly inside your containers. If you need state on the server it needs to be in some external data store.
Use JWTs or an external IDM (that will generate JWTs) for authentication. Keep session data on the client side as much as possible and pass the JWT in every API call to authenticate the caller. If you are implementing login on your own the only APIs you need to expose without tokens are for auth and password recovery, which you can separate into their own service.
Database selection depends on how well you understand your processes, how transactional your services are and your existing skillset. Overall I would use what you are comfortable with, you can probably succeed with a lot of things. Certain NoSQL flavors can seem simple on the surface but if you don't have a clear understanding on the types of queries you need to run they can get tedious to work with. Generally you should stick to relational databases for OLAP style implementations and consider NoSQL for OLTP. Personally I like MongoDB and it is very popular, probably because it sort of sits in the middle of the pack which makes it fit a lot of applications. Using MongoDB also makes you cloud agnostic since it is available on every platform. Using platform specific database flavors can lock you down to a specific vendor.
Whatever you do, don't start installing things on VMs. You can be almost 100% sure you are doing it wrong if this comes up. Remember, the services you consume don't all have to be managed by Google or even run on GCP. You can get MongoDB capacity directly from MongoDB who manage it on your behalf on all of the Big3 cloud vendors.
At least think about the long term, even if you don't necessarily need to have it impact your architecture right now. If you are expecting your app to be up for years try to make it more platform agnostic than less. This might mean sticking away from some really platform specific serverless features that will force you to jump a couple of extra hoops. If you are using Cloud Run you are using containers which already makes your app pretty portable, don't lock it to one platform by using a lot of platform specific features. That being said, don't stay away from them either. You should always go for the low hanging fruit, so don't try to avoid using things like secrets manager etc. If your app has a short lifespan and you need really fast time to market then don't worry about it.
Just my 2c, what you are doing is very generic and can be done in a lot of different ways.
I am looking for the best way to test this scenario using automation. Before you mention or ask, yes, i have throughly searched to make sure or even get info or knowledge on this topic.
I have a web service that provides various pricing for health insurance. The pricing is based on different class category of race, age, location etc. All that is inputed into the web service to get the fee for the client.
Right now everything is done locally with SoupUI. As you know SoupUI does not have a way for you to randomly change the data in the body, but i need a way to automate this so random age, race, location, etc can be inputed in and verify the result against a CSV file with the information.
Is this possible or is there a better way to test this web service?
-
Per #lloyd request, because he is King here and other known methods i know:
UI Option: We build a UI to interface with the API and use Selenium to run the countless scenarios we have, but they do not want to do this. They are more incline on testing the API itself.
Ruby: Use Ruby to connect to the API, using Rspec and Airborne (https://github.com/brooklynDev/airborne), the downsize of this is also the same as using SoupUI. Everything is entered in manually, and the code just runs through the various variations we have to get the return and match it against what it should be.
I also found another tool, https://assertible.com/ but the downsize of that is we cannot limit the random generator between 2 selected numbers, plus no way to do the comparison.
Then there is Postman, which is also similar to SoupUI so not a real automation since we cannot change the values in the body. http://blog.getpostman.com/2015/09/03/how-to-write-powerful-automated-api-tests-with-postman-newman-and-jenkins/
I am interested in learning to use the Smartsheets API. In the past I created workflows in Google Apps Script, which has a built in IDE that houses the script. Does Smartsheets have something similar? If not, where is a common place to keep your code and have it react to webhooks/events?
Regards,
Shawn
The API is just a way to communicate between your application and Smartsheet - there is no hosting for your executable code. Smartsheet provides a number of SDKs to help make the calls easier to perform, but in theory you could use any language to make the REST commands. So, pretty much any service that allows executable code would work, such as Amazon AWS, Google Cloud, Microsoft Azure, or others. Here's a brief comparison of services.
You can start developing on your own computer before you worry about cloud deployment. See the getting started guide and samples here: https://github.com/smartsheet-platform/getting-started
If you really need to respond to webhooks, your code will have to run somewhere that accepts incoming HTTP calls from the Internet without being blocked by a firewall. This could be in your data center, any of cloud services, or via a tunnel such as https://ngrok.com/
I'm trying to figure out a way to automate testing for Single Sign On (SSO).
For us the process is as follows:
The user logs onto https://www.identityprovider.com
They click a link that takes them to our authentication server (the application that we are testing).
They are automatically logged into one of our web application (www.serviceprovider.com).
Writing useful unit tests for this seems to be difficult because of the protocols used for SSO (SAML, OAuth), and so I thought that a good way to do the testing would be via recorded step testing through something like MS Coded UI tests or Selenium. We would prefer to go with MS Coded UI tests because of the integration with the VS solution.
That said, can anyone tell me if I can start my CodedUI test from an external website (for example: google.com), or am I limited to my local solution?
You are able to hand code that.
BrowserWindow bw = BrowserWindow.Launch(new System.Uri("http://google.com""));
We are using Integration Manager to create a batch of monthly invoices. I want to build a replacement that creates a batch in GP and imports the invoices into the batch. After review, the batch will be posted to GP. Is this doable with either of these API's and which would you choose?
Integration manager can use econnect for its insertion engine. If you are processing a high volume of transactions, you will notice a huge difference between integration manager's UI engine and econnect. When you create a new integration, simply choose the econnect option and whatever data source you have set up.
Concerning the non-IM APIs, both may be used, and they are situational. The web services sits on top of econnect, and it is much slower integrating because you are passing information between several layers. It does provide a secure link between your SQL server and any outside integration sources, and it is ideal if you need to setup something to allow integrations to happen through middleware such as a billing gateway. If you have access to build an econnect process/app that makes a connection to your SQL server for GP, this is the fastest way to integrate SOP and receivable transactions. It maintains all the business rules to help ensure GP does not break in as a result of a patch, and the speed is fast enough to push thousands of records without requiring a custom integration solution.
If you want to get done quickly, and do not mind working from the integration manager interface, just build your integrations using econnect. If you have the time to develop a custom integration routine, go for econnect. If you want to leverage WCF technology on top of econnect, go for web services.
Each are listed in the amount of time it will take you to develop from fast implementation to slower implementation.