# Module migration
In this section, you migrate the
pofe module from your v0.39 application.
# Module differences
Before you start the migration, review the differences between v0.39 and v0.40 and later Stargate modules. This overview shows the differences for modules that are scaffolded with Starport:
One of the key differences is the integration of gRPC and protobuf in your application. Protobufs are an efficient method for serializing messages and the current industry standard.
# Scaffolding your Stargate module
In theory, you could copy a module from your existing application and make relevant changes based on the information in the App and Modules Migration (opens new window) documentation.
This tutorial uses Starport to generate fresh Stargate-compatible files and migrate the logic from a v0.39 application. You will also change some of the logic to make your application Stargate compatible.
The first step is to inspect the
Claim type that is defined in your v0.39 application.
ID are both default fields for Starport, we can use the
starport type command to create our
Claim type while defining the
proof as a
Once this is done, you should see a few new files added to your application -
# Protobuf and gRPC
Compared to your v0.39 application, the key differences in type scaffolding is the addition of
When you look inside the
claim.proto file, you see the following file that contains transaction (
tx) messages. It is safe to assume that these transaction messages mutate state.
You will also see a
query.proto file, which contains messages used for querying the state of the blockchain. You will notice that there is a gRPC Query service defined.
If you are unfamiliar with gRPC, a simple explanation is that each gRPC query is registered with a message structure that it receives, and the message structure of the response. For example,
QueryGetClaimRequest would require an string
id, and would return a
Claim, which is defined in the
claim.proto file in the same directory.
As a matter of fact, these messages will be used to generate the messages used in the application. You will notice this in
x/pofe/types/claim.pb.go - take for example the
Claim type. There will also be a few pre-generated helper functions including getters and marshaling methods for the messages.
Note that you can also generate these
.pb.go files by running
The same concept goes for the query methods - so updating the
proto/pofe/query.proto file and running the script will update the contents of
Now, we can continue to migrate our logic to Stargate!
# Migrating your logic
As the core logic that we implemented was within the CLI, we need to be able to modify the contents and adapt them to the Stargate release.
The most important file to note is the modification we made in the
As well as boilerplate
txClaim.go file in our Stargate application:
If we compare the two files, we will notice that there is a difference in how the commands are defined. For instance, the Stargate version of the functions no longer require a codec as an argument - eg.
func GetCmdXClaim(cdc *codec.Codec) vs
func CmdXClaim(). In this case, we can remove
cdc *codec.Codec from each of the functions as well as the
Another difference you will notice is how the application reads CLI commands. This includes reading the command, building the message, and Generating or broadcasting the command. For instance, the contents of the
GetCmdCreateClaim command will be updated as such when following the updates generated by Starport and described in further detail here (opens new window).
Once we finish updating the rest of our custom logic, our new file
stargate/pofe/x/pofe/client/cli/txClaim.go should look as such:
The last thing we need to do is rename the CLI commands in the
Once this has been updated, we can try to run the app with
starport serve, and our application should run as expected!
# Migrating your own application
Throughout this tutorial, you learned how to use Starport to migrate your application from v0.39 to v0.40 and later Stargate. Starport always generates the most up-to-date Cosmos SDK boilerplate code.
Although it is possible to manually change your application code, this tutorial minimizes the changes required to migrate an application. Instead of manually modifying each file that required updates, you migrated only the custom logic that was implemented. The generated boilerplate code also serves as a useful reference to examine the fundamental changes within the application.