Can you import existing chain code?
Can you use existing blockchain applications with a new business network?
No, you cannot import or call existing Go chaincode from Javascript transaction processor functions.
You can migrate existing Protobufs to Composer models using this utility however:
https://github.com/fabric-composer/tools/tree/master/composer-protobuf
Related
package main
import (
"encoding/json"
"fmt"
"strconv"
"github.com/hyperledger/fabric-sdk-go/pkg/client/channel"
"github.com/hyperledger/fabric-sdk-go/pkg/client/event"
"github.com/hyperledger/fabric-sdk-go/pkg/client/ledger"
"github.com/hyperledger/fabric-sdk-go/pkg/client/resmgmt"
"github.com/hyperledger/fabric-sdk-go/pkg/common/errors/retry"
"github.com/hyperledger/fabric-sdk-go/pkg/common/providers/fab"
"github.com/hyperledger/fabric-sdk-go/pkg/core/config"
"github.com/hyperledger/fabric-sdk-go/pkg/fabsdk"
)
type Degree struct {......
I am new to Blockchain programming and I am trying to build a degree verification application with the help of my friend. We wrote the whole program, Installed/Set Up Hyperledger Fabric, Go on Ubuntu 22.04. When we try to run it using
go build fabric.go (or) go run fabric.go
We get the following error,
fabric.go:7:2: no required module provides package github.com/hyperledger/fabric/core/chaincode/shim; to add it: go get github.com/hyperledger/fabric/core/chaincode/shim fabric.go:8:2: no required module provides package github.com/hyperledger/fabric/protos/peer; to add it: go get github.com/hyperledger/fabric/protos/peer
We tried installing the required Go module dependencies as it suggested and we keep getting
go: module github.com/hyperledger/fabric#upgrade found (v2.1.1+incompatible), but does not contain package github.com/hyperledger/fabric/core/chaincode/shim
and
go: module github.com/hyperledger/fabric#upgrade found (v2.1.1+incompatible), but does not contain package github.com/hyperledger/fabric/protos/peer
I have no idea how to proceed further and I could use your help. Please explain it as if you are explain it to a five year old, because as I said I am new to this and I am not fully versed with all the terms. I am learning fabric by making projects.
I don't really see enough information in your question to see where your problem is occurring and therefore how to solve it. You should not be importing any packages from github.com/hyperledger/fabric/.... This is the core Fabric server implementation and it is not intended to be consumed as a library. Neither the client SDK or chaincode APIs should be importing these packages either, so I am not sure what in your code is referencing them.
If you are just learning Fabric, I would strongly recommend that you use Fabric v2.4 (or later) and use the Fabric Gateway client API to build your client application instead of the legacy Go SDK. Samples linked from that documentation homepage demonstrate how to use the API to build client applications.
The Fabric documentation on client applications describes the key elements of the client application API. The in-line code examples reference the TypeScript sample but there is an identical sample implementation in Go, and the API structure is extremely similar in all the supported client languages, so the tutorial should be useful regardless of your application language.
I'm not sure if this is the right forum to post this question, but I'm trying to learn gRPC/protobufs in the context of a web application. I am building the UI in Flutter, and the backend in Go with MongoDB. I was able to get a simple go service running and I was able to query it using Kreya, however my question now is - how do I integrate the UI with the backend? In order to make the Kreya call, I needed to import the protobufs. Do I need to maintain identical protobufs in both the front end and backend? Meaning, do I literally have to copy all of my protobufs in the backend into my UI codebase and compile locally there as well? This seems like a nightmare to maintain, as now the protobufs have to be maintained in two places, as opposed to one.
What is the best way to maintain the protobufs?
Yes, but think of the protos as a shared (contract) between your clients and servers.
The protos define the interface by which the client is able to communicate with the server. In order for this to be effective, the client and server need to implement the same interface.
One way to do this is to store your protos in a repo that you share in any clients and servers that implement it. This provides a single source of truth of the protos. I also generate copies of the protos compiled (protoc) to the languages I will use e.g. Golang, Dart etc. in this shared protos repo and import from the repo where needed.
Then, in your case, the client imports the Dart-generated sources and the Golang server imports the Golang-generated sources from the shared repo.
Alternatively, your client and your server could protoc compile appropriate sources when they need them, on-the-fly, usually as part of an automated build process.
Try not to duplicate the protos across clients and servers because it will make it challenging to maintain consistency; it will be challenging to ensure every copy remains synchronized.
We have an existing backend with microservices for our native apps. Now we need a support and admin UI, therefore my question, is JHipster the right generator for that and if yes, how can I create entities from my existing databases? Most of them are MySQL? As I understood I need a JDL but do I need to create it manually?
Thanks!
JHipster has no support for generating code on top of existing databases. So, you would probably have to write manually JDL for your existing entities, it can be very difficult or impossible depending on the conventions you used for naming your tables, columns and relations.
There's a module that can help to some extent https://github.com/bastienmichaux/generator-jhipster-db-helper.
However if you plan to generate only frontend code, it could be simpler because you would not depend on database structure. The effort for connecting your generated frontend to your existing backend would depend mainly on which authentication type its uses and REST API it exposes.
Just build a prototype: generate frontend only with jhipster --skip-server, write a JDL file for few entities and then import it, then see how you can modify code to adapt to your backend.
I would like to use the Solidity language to write a code of smart-contracts.
My code should be about a transfer of real estate`s assets, by spares the middlemen as much as possible.
My questions:
What are my options to create GUI and combine solidity code with it?
My GUI should be similar as much as possible to JavaFX.
Haim
You have to create Distributed Application to interact with the Smart Contract. For the development of GUI I used the Truffle Framework with the Angular Box. Truffle framework provides boxes for different technologies. The Angular box has the basic files to start with. Angular App also help you to organize your code well.
For interacting with the Smart Contract you need the Web3 libraray. The web3 library provides you interface to interact with the blockchain.
You can use React to create UI. As using react with ethereum has lot of advantages
After I've put together my business network definition, what is actually happening on peers after I deploy that package? I'm especially interested in how a hyperledger peer can be interpreting javascript, since that doesn't appear to be a supported language for chaincode.
The Composer chain code is written in Go. It uses the Duktape Javascript interpreter to execute the user (and system) JS code within a Go process.
The Composer chain code maps the public JS API to the underlying Fabric Go API calls.
From a Fabric perspective this is just a "normal" piece of Go chain code, albeit quite a complex one!
When you "deploy" a business network using the Composer CLI, you are actually doing 2 things:
deploying the Composer chain code (Go) and starting it
deploying the bytes of the business network archive and storing it in world-state, so that it is available to the interpreter when you submit transactions
In the future we would like to replace the use of Duktape by native Node.js execution. Thanks to Fabric's modular architecture (and use of Docker containers and gRPC) this should be possible.