I am new to blockchain development and to tendermint as well.
I already have a blockchain running locally.
Using this command starport scaffold vue I could mount a local web application. Inspecting a bit I could replicate some network requests (localhost) and I can get the ballance of current wallet (hard-coded on the request), get the current wallet from the localstorage. I'm struggling on authentication (mnemonic, wallet name and password).
However I also would like to costumize it according to my needs and I thought I could start a web application from scratch. I can see that the generated web project is importing this project https://github.com/tendermint/vue which is making a lot of "magic behind the scenes" and importing UI elements as well and I would like to have my own elements.
I don't want to re-invent the wheel and I can make some imports to help me on connection to wallet, validate authentication (mnemonic, wallet name and password), create wallet and so on.
I am trying to build a web application to connect to wallet, make transations.... but I would like to control the styles and the connections (and if possible using reactjs instead of vuejs, otherwise I dont mind learn vuejs as well).
Is this possible or reasonable? Where I can find good documentation or tutorial to guide me on customize a web application using tendermint. Honestly I searched but I am kind of lost.
Thanks
UPDATE: I found good examples and here and here. It helped me to validate mnemonics and make transactions, with my stack tech.
Because Starport generates both plain Javascript and VUE controllers, you have few options:
Create your own site re-using VUE components
Take plain JS part and build a website using whatever technology you like
Use a plain JS client for standard cosmos modules you can find on GitHub
Use Protobuf generator to generate light client code yourself
If you only need wallet functionality, #2 and #3 may work best for you because the bank module is stable and hasn't changed much in a long time.
You can find plain JS file for bank in your project:
vue/src/store/generated/cosmos/cosmos-sdk/cosmos.bank.v1beta1/module/index.ts
There is a link to starport discord channel related to frontend: https://discord.gg/CvbdYh9AWQ
My goal is to display data retrieved from a 3rd party (external) API that requires authentication in my Liquid Shopify theme.
I'm looking to access product options data from the Hulk Product Options API, which requires authentication, as documented here: https://productoption.hulkapps.com/api-docs/index.html
My goal would be to send a get request and retrieve data from the Hulk Product Options endpoint.
I've read that an App Proxy is what I need to set up, however I am new to the Shopify app world and am totally lost at how to set this up.
What I've done:
Followed the steps here to create an app and install it on a development store that I created through my partners dashboard.
Went to the partners dashboard, clicked "Apps" and found the app proxy section.
Questions:
What do I put in those fields? I can't find examples for filling out that section with info from an external API.
What code in which file do I need to add to the node app that was generated using shopify node create. Or is this app just necessary to be able to fill out the app proxy info?
What url can I send a GET request to using AJAX / JS in my liquid theme code?
I'm a theme developer new to app development and have never created an app, so if you can provide basic and specific instructions (code would be wonderful!) for someone who knows front-end and is competent but is lost in the app world it's much appreciated. I've asked other theme developers who also have also tried and not been able to figure this out, so there seems to be a gap in the tutorials and resources provided.
Thanks in advance!
I'm building an application with Vue and Electron, and I'm wondering what the best approach is for authenticating users.
I'm using JSStore as a wrapper for IndexedDB as my database. I'm familiar with using bcryptjs as a means for authenticating users when I create Node backend and have traditional /login or /signup routes.
But this is where I'm starting to get confused. Do I need to set up a Node server to start up when my application starts up? Because given that I'm using IndexedDB, I don't know that it makes sense to have a process of Sign Up --> Request to Node Server --> Send data back to browser
Would I be better served using a different type of database? Could I do something such as adding bcryptjs to the Vue prototype, so that's it's accessible where I need it to work with JS Store? Are there security concerns that I should be aware of with an approach like that?
At this point I'm stuck, and have more questions than answers. I've done some looking around for articles, and I find a lot of content about setting up authentication with Vue, but not within the context of an Electron application. I'm not sure how that variable changes things.
Any advice or direction would be greatly appreciated.
JsStore is client side technology, which means if you are setting up authentication in client side, it will be available only to that device.
Let's understand it more by use case -
Say your application named My Awesome app has authenticaion implemented. User register it and then they are able to use it after registration. They are logging out and signing in again with registration data and everything is working normal.
Here is what wrong with this approach -
User buys another pc and installed application My Awesome app, he tries to login but unable to login because registration data does not exist on their new PC.
Due to some issue, user hard disk crashed & he installed new hard disk. Same thing as above he is not able to log in.
So it is recommended to implement the signin on some server & keep data there.
I have been a dev for some years now, but I can't wrap my head around what exactly is a PWA.
For example, if an app runs on a mobile phone it is a native app. I can point to it and tell people that "look it is a native app."
In a similar sense, what is a PWA? Where does it run? Which app can I point to and tell that it is a PWA?
From what I have read on the web I feel that a PWA is a website that has modern technologies and gives a "native app like" experience to the user.
Is my understanding correct?
All in all, it is a website that has native-like experience?
If so how does a user separate a normal website form a PWA?
The concept of the progressive web app (PWA) was approached by Google in late 2015. They are basically web applications (Website) but have look and feel like other native mobile apps. The progressive web app enabled websites can offer functionalities such as working offline, push notifications, and device hardware access.
Benefits of the progressive web app:
1. Smaller and Faster:
The progressive web apps are much smaller in size than native apps. They don’t even need to install. That’s they are not wasting disc space and load very fast.
2. Responsive Interface:
Progressive web app (PWA) supported web pages are capable to fit in every screen sizes automatically. It could be a smartphone, tablet, desktop or laptop.
3. No Updates Required:
Most of the mobile apps need regular weekly updates. Like the normal website, progressive web apps (PWA) are always loaded latest updated version whenever the user interaction happens and no App or Play Store approval required.
4. Cost Effective:
Native mobile apps need to be developed for both Android and iOS devices separately and their development cost is very high. On the other hand, progressive web apps are had the same features but the fraction of the prior price.
5. SEO Advantage:
Progressive web apps are discoverable by search engines and load super-fast. Just like other websites, their links are sharable too. This, in other words, gives good user experience and result in SEO rank boost.
6. Offline capabilities:
Due to the support of service worker API, PWAs are accessible in offline or low internet connections.
7. Security:
PWAs are delivered over HTTPS connection and secure user-data over each interaction.
8. Push Notifications:
By the support of push notifications, PWAs can interact easily with the users and provide a really amazing user experience.
9. Bypass the app stores:
PWAs don’t need the App store or Google play store support. Their updated version can be directly loaded from the web server without the requirement of app store approval. On the other hand, native apps need days of approval if any new update required. There are possibilities of getting rejected or banned.
10. Zero installation:
During browsing, progressive web app gets its own icon on phones and tablets, just like a mobile application, but without the need to go through the tedious and slow App Store installation process.
Disadvantages of the progressive web app:
1. Less access to system features:
Currently, Progressive Web Apps have limited access to native system features than native apps. Also, all browsers are not supporting its full features but maybe in near future, it will be the new standard of development.
2. More Android – Less Apple’s iOS:
progressive web apps are currently, most supported by Android devices. Apple’s iOS is only partially supporting.
3. No review standard:
progressive web apps don’t need any kind of review system which is applicable for native apps from the app store. It may make the process faster but lack of promotional benefits from the app store.
Progressive web app checklist:
The checklist for the progressive web app is extensive. I have described its main few items here.
1. HTTPS
2. Web app manifest - manifest.json
3. Service worker
4. Responsive design
5. App icon
6. First load fast even on 3G
Conclusions:
There are huge possibilities offered for the progressive web app. Although there are lots of features and browser adaptability expected in near future. But, whatever already exists in the market is enough to show a strong mobile presence.
Visit the video blog: https://www.youtube.com/watch?v=NVXP-RzA0Eo
A PWA is a website with certain progressive features, most notably the ability to load offline or in areas with spotty connection, load quickly, display push notifications, and have other native app qualities. The benefits of a PWA is that they run on any browsers (since they're a normal website, if the browser doesn't support PWAs then the user gets a normal website experience), even desktop browsers. On mobile devices, the user will often get prompted to install the web app to the home screen, which happens almost instantaneously and uses barely any data since the website is already loaded. This allows for way more "downloads" than a native app, leading to higher engagement. For another brief overview of what a PWA, Google has some great articles about them.
Technically speaking, a PWA is a website that has two things: a web app manifest file and a service worker.
A manifest is a JSON file (usually called manifest.json) with some information about the progressive web app. It contains information similar to what you would include with a native app. It has the name, the short name for display on home screens, icons, orientation, etc. A web app manifest can be used on any site (even non-PWAs) to give the browser more information and allow the site to create a shortcut on the user's homescreen, but it's required for a PWA. You can read more about it over on the Google Developer's site.
A service worker is a JavaScript file that can be installed by the browser to do certain tasks. This file will be run in the background of the site and can do things like caching resources, intercepting network requests (to do stuff like return data from the cache), receiving push notifications, background synchronization, etc. When a user first visits your site this JS file gets installed and starts running. This is the file that allows for things like offline functionality. You can read more about service workers on the Google Developer's site as well.
Roughly speaking PWA is a web app that has native feeling and can be installed to the users' home screen and can start & work offline with an optional sync to server when Internet connection gets available.
To be considered a Progressive Web App, your app must be:
Progressive - Work for every user, regardless of browser choice,
because they are built with progressive enhancement as a core tenet.
Responsive - Fit any form factor, desktop, mobile, tablet, or whatever
is next.
Connectivity independent - Enhanced with service workers to work
offline or on low quality networks.
App-like - Use the app-shell model to provide app-style navigation and
interactions.
Fresh - Always up-to-date thanks to the service worker update process.
Safe - Served via HTTPS to prevent snooping and ensure content has not
been tampered with.
Discoverable - Are identifiable as “applications” thanks to W3C
manifests and service worker registration scope allowing search
engines to find them.
Re-engageable - Make re-engagement easy through features like push
notifications.
Installable - Allow users to “keep” apps they find most useful on
their home screen without the hassle of an app store.
Linkable - Easily share via URL and not require complex installation.
I think PWA is quite a broad term. I say broad because there are many ways of developing and distributing a PWA. In Layman's terms a Progressive Web App is a 'web site' that is effectively used/displayed like a native app. I believe an example of this would be something like phonegap? where phonegap built an app 'surrounding/scaffolding' and displayed a webpage with some custom CSS over the top. (Editorial Note: Phonegap is not related to progressive web apps. Phonegap creates actual, native applications. Wrapping a website in a native application is very different from progressive web apps.)
Most recently though I've been working on a lot of react only based website which I believe is the closest to PWA you can get at the moment (especially for IOS who only support minimal feature to encourage you to build native apps for their app store).
But yea it's basically an app like app that's not an app; rendering from a web page :thumbsup:
Progressive Web Apps (PWAs) are web apps that follow a set of guidelines
Starts fast, stays fast
Performance plays a significant role in the success of any online experience, because high performing sites engage and retain users better than poorly performing ones. Sites should focus on optimizing for user-centric performance metrics.
Works in any browser
Users can use any browser they choose to access your web app before it's installed.
Responsive to any screen size
Users can use your PWA on any screen size and all of the content is available at any viewport size.
Provides a custom offline page
When users are offline, keeping them in your PWA provides a more seamless experience than dropping back to the default browser offline page.
Is installable
Users who install or add apps to their device tend to engage with those apps more.
For more details see What makes a good Progressive Web App?
I want to control a mac app via a local website. I think the best way is to create a webserver with my mac app and then to send (primarily) integer values from the website and vice versa.
I found already CocoaHTTPServer, but I'm not sure how to do it.
For start with I want to have a slider on the website, that updates a slider in my mac application (and vice versa)
You will initiate on a separate thread or operation the web server and always wait for incoming requests. Whenever you receive a request you will handle it accordingly.
Also, if you are using this: https://github.com/robbiehanson/CocoaHTTPServer/
then there are a few examples that show how to do it. Copy the code from there to begin with the web server handling requests. After that, think through what you want to send and what you want to do. Build a form or something for the web site and submit a request to the web server.
CocoaHTTPServer will let you embed the web server into your application, which is a fine solution for what you're trying to accomplish.
Some thoughts on how to engineer it:
You'll need to subclass HTTPConnection.
Model your solution on the PostHTTPServer example.
You could get the data you want to send into the URL. Something like POST http://localhost:12345/updateSlider/123. (You probably don't need an actual POST, but no reason it wouldn't work. Technically a PUT would be more correct.)
Start by handling that part – where the browser sends a value to your application. To generate POST/PUT requests for testing purposes, use curl, or else build a static page and open it in your browser.
When you get that working, then worry about presenting a web page to the user.