I am learning solidity from last 3 months but now I am confused how to connect your contract with frontend (with react or next).
Every developer has their own way of applying it as i am, i want to with the best way
like with hardhat or truffle
Regarding connecting to the provider, #web3-react (docs) is the most used package I believe. It supports a wide variety of connectors (Metamask, ...) and you can find some good examples by googling.
Then you need either "ethers" or "web3js" to send transactions, etc. Choose whatever you're already familiar with.
IMO, A good boilerplate to start coding on web3 is:
Frontend :
ReactJs (CRA)
ethers.js : A great library to let you interact with smartcontract through ABI json file, Events and Transactional functions. This package is considered a MUST USE for a beginner IMO.
#web3-react : Written by creator of Uniswap.org, Good library to work with ethereum compatible wallets, but not necessarily for you to use. you can handle connecting ethereum compatible wallets on your own.
SmartContract :
Hardhat
Ganache
RPC Urls , you may obtain testnet urls by providers like Infura and etc.
Generally speaking of a web3 project, a backend is nothing but a RPC Node who speaks to blockchain, So using ReactJs or NextJs is up to you. But for a beginner I would recommend using ReactJS only. I suggest you look into reputable sources such as Uniswap and OpenZeppelin
Related
My website will perform CRUD operations and will work with MongoDB and Firebase storage+auth.
What are the reasons / advantages to developing a separate Express server instead of integrating everything in my next.js app?
As far as I have seen, it can all be done in my next.js app, but I still see many projects working with a separate server.
Depends on what your app does and how you are hosting it.
Running Next.Js on a standard server will be of little difference whether you are using nextjs's /api or expressjs.
However if you are hosting on serverless (e.g. Vercel), I would recommend using a separate express server if you have alot of CRUD operations because the warming up of serverless is really bad user experience.
Build and Deployment
Next/JS - If you want to edit something on the backend, and push the changes, it will require you to build the entire JS app, and depending on how big is your app, it can take alot of time (especially if alot of static generated pages).
Express - If you running express separately, you can build and deploy front end and backend separately. It's time saving, and you can also better organise your codes frontend/backend.
Choice of deployment
I have a choice to take advantage of Vercel to host my frontend, with static generated pages and some server side generated pages (automatic scaling, caching, CDN etc), and host my backend with a separate cluster of servers.
PS: I moved from single Next.JS app to NextJs+Express
I can think of a few things why they would have a different server from the one NextJS provides:
Familiarity with Express, Koa, etc. All next-connect helps with this
There is an already existing API in PHP, Express, Flask, etc.
It is literally based on what you would want to do, the extra interactions with MongoDB & Firebase would be same on both the technologies, unless you want to isolate respective things separately, I don't see any harm in doing everything together on next.
Given that the idea of using next.js, as per my understanding would be to utilise server side rendering.
I've been using Next.js with Typescript for quite a while now and I, as of now, have found one reason not to include express.js in my project. And the reason is Vercel.
Since I use Vercel for continuous deployment of my projects, and Vercel Not supporting any custom server as of there Docs here, I refrain from using Express or any other custom servers.
I didn't face any problem performing CRUD operations with MongoDB, can't say about firebase.
On Next.js Docs, I found these points to be considered:
A custom server can not be deployed on Vercel, the platform Next.js was made for.
A custom server will remove important performance optimizations, like serverless functions and Automatic Static Optimization.
But at the end of the day it very personal opinion weather to use a custom server or not. It might depend on a very specific use case you might be looking for.
Personally, I try to keep it to just NextJS, but if I have to manage real-time data with Socket.io, I get a separate server because other than WebSockets, serverless functions can do everything else.
I am planning to build a react native application, where at some point i should use a database, which database is suitable for online react native and how will i connect db with my react native code?
Databases should be linked to the server, and not directly to the app for obvious security purposes. An App is just like the front-end part of a website: if it's executed in client-side, it's not safe.
So any back-end framework with a SQL DataBase will do (PHP frameworks like Symfony or Laravel or NodeJS) You will have to get your data with react native's Linking fetch API, by adding a token if you want to limit the access to connected users only.
But good news, if you're not very comfortable setting up a server, you could always choose a server-less solution like Firebase .
I definitely recommend it. You could save a lot of time and end up with a very secure and fast solution to manage your app's data. Just be aware that only a limited number of requests per day are free (but don't worry, it's not that expensive and it gets paying only with a great number of request per day). You will have to learn how to use it by reading the docs though, it might take you a couple of days, but trust me it's not rocket science.
(Disclaimer: I'm not advertising for Firebase, I just enjoyed using it so I recommend it)
I have a socket.io server for backend and a React app as my frontend, which are located in different project folders (If it makes a difference at all). Is there a way to publish them both into one project and make them work with each other using Firebase hosting?
I have read that some guy tried to do that and a Firebase employee said it's better to use Realtime Databases. The problem with those is asynchronous calls, which makes my project useless. Socket.io helps with keeping data in order and makes everything work as intended.
Is there a way to... refractor the code to make Firebase Functions work like a socket.io? Is it worth it?
What you're trying to do is not possible with Firebase products, in the way that you describe. Cloud Functions doesn't do any streaming of requests or responses.
As another Firebase employee, I also strongly suggest you take a look at Realtime Database, since it effectively can do streaming between two clients using its synchronization mechanism.
I have no idea what you mean by "the problem with those is asynchronous calls, which makes my project useless". Asynchronous programming is very standard these days, and for JavaScript and web development, asynchronous programming has always been the norm.
I am trying to understand React to possibly create an app for Production purposes.
I am used to creating an Node Express app, and with Express if we want https we require https and in the https.createserver() we provide a path to our pem file from our CA and our passphrase to access it.
Do we not have this option to use a CA Certificate file for React? Or since it is just a UI does it not need it?
Say I have an Express API, I created using https that I can get information from using postman with no problems, and I want my React App to access my API. Is the only thing I will need to get info from my api the proxy line in my react package.json file pointing to https://api.to.call.com? I thought it was bad practiced to post or get to https server from http.
Plus I just read that Create-React-App should not be used for production. Then what am I supposed to use for production? Is there a Create-React-Production-App? Or is this something else I need to add to my express server? I am very confused about the entire setup.
React is a front-end library. As such, it has nothing to do with SSL certificates, since in the end it's just javascript code that runs inside the client interface (i.e. a browser).
React is also agnostic when it comes to your back-end. It can be Node/Express, Rails, Python, PHP, your front-end really doesn't care, all it will see is an API that provides data (usually in the JSON form) upon request.
You do not have to serve your API and your front-end files from the same server - you can, but it's a matter of preference. And to access your API from your front-end, you can use one of several npm packages, Axios is a great one, there are others (Fetch, ...) ; all you have to do is hookup your API calls using the same URLs you used in Postman in the components that require them.
As for Create-React-App, it's a nice helper tool, but I would recommend learning a bit about the React ecosystem rather than rely blindly on it. The trickiest part is probably the Webpack configuration, but once you get the hang of it, everything becomes a lot easier. There are also newer tools like poi that can do a lot of the grunt work for you. With Webpack, you can have a dev configuration (hot reloading dev server, etc.) and a production configuration (that will output your production build JS, HTML, CSS, can optimize with chunking, etc.).
I'm not very familiar with Create-React-App (I prefer to use my own boilerplate projects), but if I'm not mistaken, there is a possibility for you to access full customization of your project, see here. Be warned however, it's a one-way operation.
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.