How can playwright launch a chromium which can remember the cookie of last time?
I mean when I use Selenium, it can remember the last state and second time I don't have to handle the cookie.
Can playwright-chromium do it?
You can reuse signed in state according to this:
https://playwright.dev/docs/auth
Related
I have a rest API running on cloud run that implements a cache, which needs to be cleared maybe once a week when I update a certain property in the database. Is there any way to send a HTTP request to all running instances of my application? Right now my understanding is even if I send multiple requests and there are 5 instances, it could all go to one instance. So is there a way to do this?
Let's go back to basics:
Cloud Run instances start based on a revision/image.
If you have the above use case, where suppose you have 5 instances running and you suddenly need to re-start them as restarting the instances resolves your use case, such as clearing/rebuilding the cache, what you need to do is:
Trigger a change in the service/config, so a new revision gets
created.
This will automatically replace, so will stop and relaunch all your instances on the fly.
You have a couple of options here, choose which is suitable for you:
if you have your services defined as yaml files, the easiest is to run the replace service command:
gcloud beta run services replace myservice.yaml
otherwise add an Environmental variable like a date that you increase, and this will yield a new revision (as a change in Env means new config, new revision) read more.
gcloud run services update SERVICE --update-env-vars KEY1=VALUE1,KEY2=VALUE2
As these operations are executed, you will see a new revision created, and your active instances will be replaced on their next request with fresh new instances that will build the new cache.
You can't reach directly all the active instance, it's the magic (and the tradeoff) of serverless: you don't really know what is running!! If you implement cache on Cloud Run, you need a way to invalidate it.
Either based on duration; when expired, refresh it
Or by invalidation. But you can't on Cloud Run.
The other way to see this use case is that you have a cache shared between all your instance, and thus you need a shared cache, something like memory store. You can have only 1 Cloud Run instance which invalidate it and recreate it and all the other instances will use it.
A couple of days ago, I ran a collection of two requests in Postman.
I was using an environment variable created in the first request which was then
used in the second request.
I ran the two requests manually in the primary application interface of
Postman, one by one. The responses were as expected and there were no errors.
But when I tried running the whole collection in one go from the Postman
Collection Runner interface, the second request gave me an error.
I checked and double-checked that I was running the right collection. I closed
and reopened the Collection Runner window.
Also, in the Collection Runner window I tried switching to some other
collection, and then switch back to the collection of interest.
As I remember it, I even exported, deleted, and then imported the collection
again. None of these actions would make the error go away.
One thing I noticed was that - when running in the Postman Collection Runner -
the first request would create an environment variable with a stale name,
that is with a name I had used previously for the same environment variable.
However, when running the first request manually (not in the Collection Runner
window), the environment variable was created under its new correct name.
I cannot reproduce this behavior, and therefore I don't expect to see a genuine
solution to the issue. But a workaround would be much appreciated.
In vain I had tried just about anything I could think of.
Then I found a post at the Postman community on
How to remove some or all requests from the history.
See the second post of the link ( = first answer ). It says:
"There is also a Clear All selection at the top of the History section if
you want to remove everything."
In the Postman primary interface, just click
History > Ellipsis (...) > Clear all.
Voilà! - No error when running the collection in the Collection Runner window.
For navigation help, see the images below.
I am running Apache Superset at the following address:
http://superset.example.com:8088
That gets redirected to:
http://superset.example.com:8088/superset/welcome
Ideally, users would get redirected to:
http://superset.example.com:8088/welcome
How can that be accomplished? As well I would like for it to run under port 80 so the port doesn't need to be specified but I haven't been able to do that either.
This issue covers what you're talking about:
https://github.com/apache/incubator-superset/issues/985
which led to this closed PR:
https://github.com/apache/incubator-superset/pull/1866
You can try to reopen the PR and finish it, or you can try configuring nginx like this guy suggests.
I found it very frustrating to setup a base url for superset. If you want to save some time, I condensed a couple of comments into a working example here: https://github.com/komoot/superset-reverse-nginx-example
Below is the way I eventually made it to run on an endpoint other than '/'. But my use case is to make it work on AWS Lambda in Serverless environment.
Eventually what i did was the below to make it work:
In config.py i have added another configuration variable and used this variable in locations where redirect or appbuilder.add_link has been used.
In templates folder there are places where directly '/superset/' has been used. So, even if i did first step right, the templates are not rendering in right way. So, i have to go and change the template as well (As of now I have hard-coded this. I need to make it configurable)
In front-end i have added a file called config.ts and I have used this config in locations wherever redirect was done in front-end. This has fixed up all my front-end links.
Only thing remaining for me was fixing "Upload CSV to Database" Link. When we click this link and enter the data, since Lambda doesn't allow any writes i tried to write to /tmp - but since we don't know whether the next request is going to be served by same lambda or not... so this is an issue as of now. The way I am planning to fix this is to write the files to s3 instead of local folder. I am still figuring out a way to do this.
-- No more nginx or other links. We don't even need gunicorn in this setup.
Thanks
I'm looking to access control example. https://github.com/strongloop/loopback-example-access-control
It says we need to put sample-models.js file under server/boot folder. That means, everytime I run the application, the creation process will be made again and again. Of course, I'm getting errors on the second call.
Should I put my own mechanism to disable if ones it run, or is there a functionality in loopback?
Bot scripts are for setting up the application. And run once per application start.
So if you want to initialize database or any initializing which would be persisted by running boot script, you need to check if it is initialized first or not.
For example for initializing roles in db, you need to check if there is desired roles in db or not. And if there is not, so create ones.
There is no other functionality in loopback for this.
I just finished a Django app that I want to get some outside user feedback on. I'd like to launch one version and then fork a private version so I can incorporate feedback and add more features. I'm planning to do lots of small iterations of this process. I'm new to web development; how do websites typically do this? Is it simply a matter of copying my Django project folder to another directory, launching the server there, and continuing my dev work in the original directory? Or would I want to use a version control system instead? My intuition is that it's the latter, but if so, it seems like a huge topic with many uses (e.g. collaboration, which doesn't apply here) and I don't really know where to start.
1) Seperate URLs www.yoursite.com vs test.yoursite.com. you can also do www.yoursite.com and www.yoursite.com/development, etc.. You could also create a /beta or /staging..
2) Keep seperate databases, one for production, and one for development. Write a script that will copy your live database into a dev database. Keep one database for each type of site you create. (You may want to create a beta or staging database for your tester).. Do your own work in the dev database. If you change the database structure, save the changes as a .sql file that can be loaded and run on the live site database when you turn those changes live.
3) Merge features into your different sites with version control. I am currently playing with a subversion setup for web apps that has my stable (trunk), one for staging, and one for development. Development tags + branches get merged into staging, and then staging tags/branches get merged into stable. Version control will let you manage your source code in any way you want. You will have to find a methodology that works for you and use it.
4) Consider build automation. It will publish your site for you automatically. Take a look at http://ant.apache.org/. It can drive a lot of automatically checking out your code and uploading it to each specific site as you might need.
5) Toy of the month: There is a utility called cUrl that you may find valuable. It does a lot from the command line. This might be okay for you to do in case you don't want to use all or any of Ant.
Good luck!
You would typically use version control, and have two domains: your-site.com and test.your-site.com. Then your-site.com would always update to trunk which is the current latest, shipping version. You would do your development in a branch of trunk and test.your-site.com would update to that. Then you periodically merge changes from your development branch to trunk.
Jas Panesar has the best answer if you are asking this from a development standpoint, certainly. That is, if you're just asking how to easily keep your new developments separate from the site that is already running. However, if your question was actually asking how to run both versions simultaniously, then here's my two cents.
Your setup has a lot to do with this, but I always recommend running process-based web servers in the first place. That is, not to use threaded servers (less relevant to this question) and not embedding in the web server (that is, not using mod_python, which is the relevant part here). So, you have one or more processes getting HTTP requests from your web server (Apache, Nginx, Lighttpd, etc.). Now, when you want to try something out live, without affecting your normal running site, you can bring up a process serving requests that never gets the regular requests proxied to it like the others do. That is, normal users don't see it.
You can setup a subdomain that points to this one, and you can install middleware that redirects "special" user to the beta version. This allows you to unroll new features to some users, but not others.
Now, the biggest issues come with database changes. Schema migration is a big deal and something most of us never pay attention to. I think that running side-by-side is great, because it forces you to do schema migrations correctly. That is, you can't just shut everything down and run lengthy schema changes before bringing it back up. You'd never see any remotely important site doing that.
The key is those small steps. You need to always have two versions of your code able to access the same database, so changes you make for the new code need to not break the old code. This breaks down into a few steps you can always make:
You can add a column with a default value, or that is optional. The new code can use it, and the old code can ignore it.
You can update the live version with code that knows to use a new column, at which point you can make it required.
You can make the new version ignore a column, and when it becomes the main version, you can delete that column.
You can make these small steps to migrate between any schemas. You can iteratively add a new column that replaces an old one, roll out the new code, and remove the old column, all without interrupting service.
That said, its your first web app? You can probably break it. You probably have few users :-) But, it is fantastic you're even asking this question. Many "professionals" fair to ever ask it, and even then fewer answer it.
What I do is have an export a copy of my SVN repository and put the files on the live production server, and then keep a virtual machine with a development working copy, and submit the changes to the repo when Im done.