my use case is to explore how could a server-side requests be mocked. I am successful in mocking client side request using requesthooks but with server side testcafe is not able to intercept the request.
Frontend is built using next.js, and at intial page load, getinitalprops prepares the page by using fetch (get request) which happens at server side(node) not browser, and testcafe is not able to intercept.
I want to introduce testcafe in my team for frontend dev & their requirement is to resolve their pain of mocking server side requests before they start using testcafe for integration testing. Please suggest if this is possible with testcafe.
TestCafe works in a browser and does not know a lot about your server-side logic, so TestCafe can intercept only the requests sent from your browser. In your specific case, probably you need to modify your project by integrating some request mocking framework into your server app.
Related
I'm working in javascript(React) to create a web app that makes use of multiple APIs(Spotify, Twitch, Youtube) and so far I have been using Axios to make
the REST calls successfully. But now I have begun running into Cross-Origin Resource Sharing (CORS) errors and I have been told
that I need to make calls to external APIs from a server instead of from my client. I've never made API calls from a server and
have some questions:
Everything I am doing is currently running locally using Node and I dont have a "server" unless that's what Node counts as. Do I need to get a "server"?
Should I be creating my own API and hosting it on some server so that I can call that API from my javascript code?
How do I create my own API if that's what I should be doing?
Is there a different language I will need to use to make server-side api calls?
Everything I am doing is currently running locally using Node and I dont have a "server" unless that's what Node counts as. Do I need to get a "server"?
React comes with a bunch of development tools that use Node, including a development server. It isn't designed for production use though, so you shouldn't use it for that.
Should I be creating my own API and hosting it on some server so that I can call that API from my javascript code?
Yes.
How do I create my own API if that's what I should be doing?
Write some code which accepts an HTTP request, gets the data you want to respond to it with, and makes an HTTP response.
Express.js is a popular way to do this in Node. You can combine it with Next.js to apply server-side rendering for your React app (resulting in better performance, accessibility, reliability, and SEO).
Is there a different language I will need to use to make server-side api calls?
You can write your server-side code in any language you like.
I assume you are hosting your application on a development nodeJS server, therefor you
will need an extra server.
Yes. Create an API and call it from your frontend.
Create a server which takes http requests and does your stuff according to the route
chosen.There are many examples on how to do this with for example nodeJS+Express on the
internet.
The Language you use for the server side is your choice.
I'm making a new website with HTML, CSS, js for frontend and Java for backend (I don't know Java, my friend will do the java part) and I need to use frontend technologies (languages/frameworks) to use localhost
I am unable to find frontend technologies for this purpose. I have already tried python -m SimpleHTTPServer and node.js but as these are backend I can't use them. Also, I can't change my backend language
The important thing here is that you need to understand the terms backend and frontend.
A website is by definition something that can be loaded from a server with HTTP and it made of HTML and maybe CSS and/or Javscript.
Now by definition every code that runs on that server is the backend. All code that runs in the Browser of the user is considered the frontend. If the website only contains HTML and CSS that is generated by the server it does not make much sense to do this seperation. This means we only talk about frontend and backend if we have both.
This also means that the frontend code, that runs in the browser, must be delivered by the backend. A frontend without a backend can not exist.
Lets look on a little example. If a user enters example.com in the browser the browser will make a HTTP GET request to example.com. The server (and so the backend) will respond with a HTML file. This file now could embed a javascript file with <script src="/code.js">. Now the browser does another HTTP GET to example.com/code.js and the server (and so the backend) returns that file. In that file may be some frontend code that is executed in the browser.
Now maybe this file wants to load some data from the backend. So it does a fetch('/api/data). The browser does anotherHTTP GETtoexample.com/api/data` and the backend has to respond. Now while the backend was relativly dumb up to this point and only delivered files it now could actually execute some logic. Maybe load the data from a database or such. It then sends the data to the frontend which then can use that data to do something.
This means in production your backend has to deliver the frontend code. In this example the initial HTML file and the code.js file.
So what you want is by definition impossible. A frontend runs in the browser and so can not deliver code on localhost. If it could it would become a backend.
Now while its common that the real backend delivers the frontend code on production its not common for development. Its very common to have a seperate minimalistic server that is only used for development. python -m SimpleHTTPServer is such a tool and so would do the job.
Sometimes this is also done in production. Then your backend is for example on example2.com and your frontend is delivered by example.com. But this essential means that there runs a second backend just to deliver the frontend. Usually for production this is a full fledged web server like nginx, apache or IIS (you'll need CORS, see below). In contrast to them tools like python -m SimpleHTTPServer should not be used for production.
Now this means basically you can just use any kind of backend to deliver your frontend for development. Later you will give your code to your backend developer and he will then deploy it with his backend. However there is one open question:
How will your frontend and backend communicate?
In production your frontend can just fetch something and it will work if your backend delivers your frontend. But for development (and so testing) you probably already want to use the backend without actually starting it on your computer. For this basically there are two ways.
First your development backend could proxy unknown requests to the backend. This means if your real backend runs on example.com and you start a development server on localhost that server will proxy all requests that are not an existing file to example.com. So if you request localhost/code.js and the file code.js does exist your server will respond with that file. If you request localhost/data and you have no file named data your server should do a request to example.com/data and return that response. This is very common. Depending on the tools, libraries and framework you use for frontend development they have a integrated development server with that capability. For example if you develop with ember.js you can do ember server --proxy=http://example.com. And it will run a server on localhost:4200 with exactly that behavior. Other tools like create-react-app allow the same.
Second you can use CORS. This must be implemented by the backend and allows a frontend from another server to access the backend. This is also needed if you run your frontend and your backend from two different servers as I described before.
If the backend implemented CORS correctly you can just do fetch('example.com/data) to get your data, and this Javascript must not be delivered by example.com and it will just work. However CORS complicates security.
I'm trying to use cypress to cover our dev-server by a set of complete e2e tests.
We have a requirement to lock our dev environment under basic http authentication so nobody couldn't access it without proper credentials (both client and api).
When I'm trying to run Cypress tests they fail because of that. Server (nginx) just responds with 401 http-code.
I tried to pass credentials in url like 'user:password#domain.com', and it partially works: cypress is able to reach frontend on domain.com, but it's still unable to send any requests to our backend (api.domain.com) from within the page (using fetch) - probably because of different subdomain or something.
I'm looking for a way for forcing it to use those credentials on all requests on a domain or any other workaround that may help me run the tests.
Thanks!
This might not be an auth issue. fetch does not work with cypress. See https://github.com/cypress-io/cypress/issues/687
A workaround for it is to put this into your support/index.js file:
Cypress.on("window:before:load", win => {
win.fetch = null;
});
I have configured my Vert.x server built in Java to already handle HTTP connections properly, but I would like to add an additional layer of security through HTTPS. I use the standard fetch call to make POST requests to the server. I have searched through the Vert.x documentation already, but the only information I can find is if I use Vert.x as client code as well, but I would like to avoid that if possible. Is there a way to configure my client and server to work together to form a secure connection without having to build an encryption schema from scratch?
If I understood you correctly, you have but one VertX instance, without load balancer, and you would like to access it using HTTPS protocol.
It doesn't actually matter whether you access it through
When starting your VertX server, make sure you specify setSSL(true) and all the other arguments:
https://github.com/vert-x/vertx-examples/blob/master/src/raw/java/https/ServerExample.java#L39
One of my team members is working only on client-side (Javascript) development for a web app with a large and complex backend.
I would like to avoid the need for him install and configure a local copy of the backend.
However, I wouldn't want him to need to push every small change to the dev server just so that he can test it.
We thought about getting the client to make the requests directly to the dev server, instead of to the same domain (the localhost) but this doesn't seem practical due to cross-domain request policies and authentication problems (cookies aren't getting sent).
What are some elegant solutions for developing clients without having a local backend?
Depending on how complicated your backend is, you might be able to create a mock backend using a lightweight web framework like Sinatra. I've had some success with this technique, but the services I've been mocking have been fairly simple. In some cases the mock backend mostly serves static JSON files.
I use Charles Proxy to map the URIs of the dev server's web services to localhost (where I run a light weight web server that serves up my static development code).