We have a single Asp Core API method that is transforming provided html into PDF using headless Chromium. Currently the API method is using Puppeteer, which connects to an existing instance of Chromium using the debugging port and generates the PDF. Chromium needs to be launched before or on application start. All this works fine.
We are now considering rewriting the API to use Microsoft.Playwright instead of the Puppeteer. However, it seems that with Playwright for .Net we can't connect to an existing browser instance and we always need to use BrowserType.LaunchAsync, which creates a new instance. I can see the BrowserType.Connect available for all other APIs (node, python, java) but not for .Net.
Is there a way to avoid launching a new browser for every API request using the .Net Playwright API? It is very time-consuming and performance is very important in our case.
Related
I have a web app developed using..(PHP,MYSQL,HTML,CSS,JS,AJAX,Datatables, bootstrapjs)
Now, I want to make a desktop version of the same app, and I came across electronjs.
The problem is I dont know whether ELECTRONJS will support all my requirements.
A breif of my requirements:
My app is responsive using datatables.net library including EDITOR for displaying the data .
the datatable plugin requires ajax calls to some API (Which I developed with PHP and hosted on a server)..
but now I want to even do all the DB Operations with electronjs so that my app can work offline.
I am not sure if I can do that with electron
- calling an API (created by same app) from HTML/frontJS
- the API Returns Json data
- the Front JS displays that data on front.
Kindly let me know if this can be done with electronjs,
Well, basically yes. You can build a desktop app like this.
But you wont be able to run it offline if it depends on a server sided API. If you can rewrite your backend Code in JavaScript and use a SQLite DB instead of a MySQL you can run this as electron App.
Keep in mind that your business logic in the frontend can always be abused because it’s not hidden from the user.
FYI: Electron only runs a browser inside it’s own App container. So there is actually no crucial difference between Browser or electron App.
I am looking to use the google chrome headless browser's 'print to pdf' functionality to replace an existing way (using iText) to generate PDFs.
Is this a feasible solution considering the number of concurrent calls that would need to be processed is unknown?
Is headless browser's print to pdf functionality used in production for enterprise solutions to generate PDFs/screenshots or is it mainly meant for testing and development environments?
If processing multiple concurrent calls from a single machine would be an issue, would a serverless solution based on AWS lambda be a good way to approach this because of the scalability and the ability to do parallel processing?
I used the lambda functions for creating PDF files and it works fine. Scalability and parallel process also works as well because it is AWS lambdas.
But while I creating the working solution a got a lot of problems.
First of all, I used AWS API Gateway as a trigger for the lambda and I got a 30-sec timeout for the API request. This means time was limited.
My first solution was usage "chrome-aws-lambda" and "puppeteer-core" nodeJS libraries.
The very slow solution, if be honest. And very painful from the architecture side.
User UI -> request to back for PDF -> lambda function run the headless browser -> [ headless chrome start -> open some page -> request to the back for some data] -> wait for loading -> create snapshot -> response with PDF
Then I tried some libraries and stoped on "dynamic-html-pdf". This lib uses "handlebars" template and "html-pdf" lib as engine. If you have not some dynamic data on the page (f.e. dynamic list of items or some if statements) - you can use "html-pdf" only.
I have a Swing desktop application which needs to be updated periodically with details from REST response. Now the app needs to hit the REST url whenever there is an email received in an outlook folder(exchange server). I have the app packaged in a runnable jar file. App will always be running in the background.
Now I can't use javamail as it requires authentication in a plain file, which is not feasible for me due to security reasons.
I got another option which is to hook a VBscript to the outlook folder and then somehow run the Java method inside my swing application's code and update the Swing UI in background.
I'm not sure how can the VBScript be used to call a java method of a running app.
Anyone has an experience on any of the above option or has an alternate solution?
Thanks in advance.
I want to verify an ajax call was triggered
and also I want to detect a call to external custom protocol was triggered.
I think I will be able to read that data in this way only.
No, Selenium is not meant for such use case. Selenium WebDriver is just meant for simulating user interactions with web app. If you want intercept network requests, add custom headers etc during your selenium tests, you can use a proxy. BrowserMob proxy is popular for such use cases with selenium tests. It has a REST API too.
The new version of UFT 12.01 is supporting up to Chrome 36 when it comes to web content.
What about Chrome´s extensions though?
I read somewhere that they cannot be automated.
From the other hand side, when I use developer tools (12) I can identify buttons, textboxes etc.
Is it possible to test a Chrome extension by using UFT?
PS: I specifically try to automate one extension called POSTMAN - Rest Client (https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en)
UFT's Chrome support doesn't work with other extensions since Chrome disallows extensions being injected into other extensions.
As a workaround you may be able to use UFT's Insight option to automate any technology that UFT doesn't support directly.
Specifically for the Postman extension, this is a simple REST Client. I Assume you want to use it in order to test your REST services rather than actually testing the Postman extension. If this is the case wouldn't a more natural way to approach this issue be to use a UFT API test?
API tests support calling and validating REST services with all the functionality previously available in HP's Service Test.