# Module migration
In this section, we will be migrating the
pofe module from our Launchpad application.
# Module differences
Before proceeding with the migration, it is important to note the differences between Launchpad and Stargate modules. Below is an overview of the differences when scaffolding a module 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 over from your existing application and make relevant changes based off this (opens new window) document - if that is your preferred method, of migrating your modules, then you are better off following the aforementioned documentation.
Instead, we will be using Starport to genrate fresh Stargate-compatible files and migrate the logic from our Launchpad application. Note that we will also have to change some of the logic to make it Stargate compatible.
Essentially, we need to inspect the
Claim type that is defined in our Launchpad 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 Launchpad application, the key differences in type scaffolding is the addition of
If you take a look inside the
claim.proto file, you will see the following file which contains transaction (
tx) messages. We can always assume that these transaction messages will 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, we have shown you how to migrate your application from Launchpad to Stargate with the help of Starport, which will always generate the most up-to-date Cosmos SDK boilerplate code. One might be expectd to migrate their application manually by following the documentation, which is still a viable options, albeit less efficient.
The approach we used in this tutorial minimizes the changes we had to make when migrating the application - we only had to migrate the custom logic that was implemented, rather than modifying each individual file that needed to be updated. Having boilerplate code also allows us to reference it as an example when examining the fundamental changes within the application itself when making the necessary changes.