Hi I’m building a front end web app using reactjs, my app will map over different array of dogs/cats/animals with multiple props and a couple images each. The ui has a search box which then filters out relevant animals.
My question is if my list were to get quite large, do I need to have it stored in a back end ? Or can it all be stored in front end, there will be no sensitive information or anything. So im not worried about security. I do not need to receive any information from the users. Basically it’s just a website for people to browse through.
And my second question. Once deploying to a host, Im currently leaning towards AWS. Is updating/adding/subtracting from my arrays simple as deleting the file and adding the new one into the bucket ??
Sounds exciting! But let's first back up a bit, and take stock of what we're trying to do. Essentially: we want an app that will show a bunch of images with functionality (e.g. filtering).
All images/photos (e.g. this cat photo) are hosted somewhere. Period. So, you can be the one responsible for hosting the images, or you could just have <img /> tags in your react app and refer to an existing img src links, where the image sources are being hosted by someone else.
So to answer your question: my question is if my list were to get quite large, do I need to have it stored in a back end ?
Not necessarily - if you're just referencing a bunch of images from a site that someone else is already hosting, then you're good.
As for this point: Or can it all be stored in front end, there will be no sensitive information or anything.
This question is kinda hard to answer, because nothing is really ever 'stored' in the front-end (let's ignore caching). Images live on the server, and the client (e.g. your chrome browser) makes requests to the server to get the images.
Now: if you want to upload your own photos or let users upload their photos. That's a very different story.
You would want to use s3 buckets. They could host your images.
However, based upon your post, I really think you should start step-step, and not host your own images (i.e. not have a backend), and instead just start by using images already on the internet. Good luck :)
Related
I have a bootstrap input field for images in my react app. When I upload an image through it, I want to get a public URL of that image so that I could reuse it in another part of the app.
<div class="mb-3">
<label for="formFile" class="form-label">Product Image</label>
<input class="form-control" type="file" id="formFile">
</div>
I've seen people connect to an API like google drive and upload the image to get a kind of shareable link. Is there a way to do that on the client side?
Thanks for the notice :)
Using google drive as a backend is one solution, their API is a good starting point. In general IMHO you want to explore the "serverless" concept. Amazon has a lot of services available in this area.
No, you have to have a publicly accessible system to serve images. That means a server.
I can't think of any way to come close this without involving some kind of 3rd party system/server. Even if you were to do something as involved as a peer-to-peer system of sharing images over WebRTC, you would still need a signalling server to make the initial connection between clients.
The way that apps work with content sharing in a generalized manner is that a user will upload an image on the front-end to some content repository. That could be your own content repository or some 3rd party site like imgur, Google Drive, etc. Once it's uploaded, a link to that publicly available content is stored by your own application and then used in some way such as being shown on a user's content board or profile.
For example, Stack Overflow itself integrates with Imgur so that whenever you need to upload an image to go along with your question/answer it is associated to your post and hosted out of imgur. SO still has to plumb all associated stuff like knowing who uploaded what and what question it's related to where to put it in the post.
Providing a complete solution would be too broad, but a possible, birds eye view could be something like:
Serve front-end however
Serve back-end that has content accepting mechanism (maybe something like Strapi
Hook the front-end up to use the content accepting endpoint
Have a main page that just shows all the images that have ever been uploaded
Bear in mind, that it's rather complicated to do all this and curating content is also a HUGE endeavor whenever you have to deal with people uploading illicit content.
I have an e-commerce react app, so as you know every product has at least three or four images, so to show the image of product in my website i created a folder with a name of " images " inside the public folder so everytime i want to show images of a specific product i can get and show them very simply and for Now this is very very awesome.
The Problem:
as we know each e-commerce website should have an admin where he can publish new products and upload new images, so by the time may be i will have thousands of images in my website.
Question
what is the best practice to store images of my react app ?
do i need to use third party like AWS or Firebase ?
Thank you.
Storing images in the code-base assets folder is not the best option for large number of images. Handling updates, inserts is a big problem. So you have the following options.
Options: Cloud/On Premises
You may store in the cloud like AWS S3
If you want to store on premises, you may store in MongoDB Grids
or even on the File System with file-path stored in the database.
Step Ahead
But going ahead you might need responsive images according to the image placeholder. Example for an image you might need thumbnails of different sizes lets say for listing pages, android apps, iOS apps.You might also need to compress the images in case they are heavy for web purpose.
In that case you may choose to store the images in the desired
resolutions.For this you'll have to store multiple versions on an image. For example product1/original.jpg, product1/compressed.jpg, product1/300x300.jpg etc
You may resize/crop the images on the fly. If you want to write your resizing systems you may write ImageMagick/vips/PIL etc based code.You may try to search for readymade nginx based plugins to server responsive images.
If you do not want to do this resizing stuff yourself you may use image storage services like imgix,cloudinary,akamai that provides CDN + image manipulations.Some of these provide storage+manipulation while some only manipulation.
I want to upload the image in my website. The same image will be shown in another website. So this is the scenario where image is uploaded in one website and displayed in both website. These two websites are hosted in two different servers as well as they both have their own database.
I am using Angular JS, Entity Framework, Web API and SQL Server 2014 as backend for both of the website. Currently I am using ngFileUpload to upload the images. Please answer me on below questions:-
Should I upload the image in database(as nvarchar-max) or filesystem(FTP or local web server file system)? I read many articles and get to know that Database retrieval of image has affect on performance but it is more secured. However File System is easy in performance but complex on maintenance like back ups. So I am just not able to decide which to choose among these two as both have pros and cons. Which option will be more suitable to my requirement where same image will be displayed in both website. Please note that there can big images like upto 5 MB uploaded in the application but the number of images will not be huge as compare to any social networking or online shopping site.
How to create different size of images(thumbnail, medium, large etc) automatically upon uploading of image in website? Is there any tool or directive already available in Angular JS to achieve this?
I know my question is broad but I need suggestion to start with my requirements.
Please help.
I use the file system to host my images. If the image is displayed on someone's computer screen, they can use an image capturing software to copy it anyway. Also, while storing them to a database may be more secure, I don't need the extra overhead in my code where a simple url to retrieve the image will suffice.
As for resizing an image using Angular, check out these links:
https://www.scientiamobile.com/page/angular-image-resize
https://github.com/FBerthelot/angular-images-resizer
I have a WordPress site that shows posts that it gets from rss using a plugin.
I want to split the "jobs" in 2 different websites because in this configuration is not working properly (high amount of rss sources to be parsed).
I need to set one site to get the posts, and the other to show them on a template; i dont want to have the rss plugin on the site that display the posts.
Is this possible using the same database, same content but different wordpress configuration?
Is there another solution to have 2 different databases and autoupdate one from another?
Any ideea other then these 2?
Thanks
if I understand your problem correctly the solution will depend on what you can do to resolve this issue.
Firstly I think you only need one website the issue you have sounds like your website is displaying items directly from the many RSS feeds which will be slow, instead I would recommend creating a process to import the posts on a daily basis to then get written to your database.
This will probably take the form of a cron job on your server.
However if you don't have access to do this I would recommend creating pages in the back end that will import the rss content when you click import.
Is it possible to have a mobile website that can still function if there's no internet connection?
The user should still be able to use the website (if he has visited that page before), see the data (that was loaded before), add new stuff (cache locally).
When internet connection comes back online, all changed local data should be pushed online.
This should be a complete webbased solution, not a native app.
You should have a look at HTML5 offline storage, see http://diveintohtml5.ep.io/offline.html and the Offline Web Applications spec as a start. There are also quite a few posts here on SO.
Bookmarklets work when a user is offline. The trick with a bookmarklet is that it's entirely self contained javascript wrapped up in such a way that it can live within the bookmark itself. E.g. a javacsript: URL. You can also have a data: URL as a bookmark, which could be a complete HTML page. Usually these are base64 encoded with a mime type.
Probably what I'd do would be have a small base page as data:text/html,base64 which contained whatever offline content you cared about, but periodically tried to bootstrap the rest of the "real" content from wherever you host it.