Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.

This article also participated in the “Digitalstar Project” to win a creative gift package and creative incentive money

  • directory
  • preface
  • The status quo
  • demand
  • Implementation scheme
  • Conclusions and Reflections

preface

For multimedia storage service, generating cover of vod video file should be one of the very basic functions, and the multimedia storage service we are developing is facing such a demand. Because this multimedia storage service is from scratch, the lack of part of the basic function of the situation, you big guy don’t laugh.

However, because of the development from scratch, many problems that had previously been ignored gradually surfaced. This experience is very valuable, I also learned a lot from it.

The status quo

First, let’s take a look at the current state of multimedia storage services.

At present, the multimedia storage service provides basic functions such as uploading, downloading, viewing, previewing, transcoding, querying, and deleting.

The file structure is defined as follows:

type File struct {
	// DefaultModel adds _id, created_at and updated_at fields to the Model
	mgm.DefaultModel `bson:",inline"`
	Name             string  `json:"name" bson:"name"`
	Md5              string  `json:"md5" bson:"md5"`
	Type             string  `json:"type" bson:"type"`
	Url              string  `json:"url" bson:"url"`
	Path             string  `json:"path" bson:"path"`
	Duration         float64 `json:"duration" bson:"duration"`
	CloudUrl         string  `json:"cloudurl" bson:"cloudurl"`
	Filekey          string  `json:"filekey" bson:"filekey"`
	Size             int64   `json:"size" bson:"size"`
}

type FileArray []File
Copy the code

All of the above functions are based on this structure.

demand

Now there is a new requirement to generate covers for video files. How do we design the implementation?

In fact, the general scheme can be divided into two categories. One scheme is to expand the cover related fields on the basis of the original file structure, the other is to manage the cover as a separate file and associate with the original file. The differences, advantages and disadvantages of the two will be analyzed in detail below.

Implementation scheme

Scheme 1: Expand the cover related fields on the basis of the original file structure

In this case, we extend the existing file structure by adding the address associated with the cover, so we add a CoverURL field. At first glance, nothing seems wrong, but a deeper analysis will reveal the problem. If we need to delete the on-demand video file later, theoretically, the corresponding cover file should also be deleted. At this point, you will find that adding only one of the above fields is not enough, and the operation handle is missing. Therefore, we also need to add a field CoverKey.

According to the above scheme, the modified file structure:

type File struct {
	// DefaultModel adds _id, created_at and updated_at fields to the Model
	mgm.DefaultModel `bson:",inline"`
	Name             string  `json:"name" bson:"name"`
	Md5              string  `json:"md5" bson:"md5"`
	Type             string  `json:"type" bson:"type"`
	Url              string  `json:"url" bson:"url"`
	Path             string  `json:"path" bson:"path"`
	Duration         float64 `json:"duration" bson:"duration"`
	CloudUrl         string  `json:"cloudurl" bson:"cloudurl"`
	Filekey          string  `json:"filekey" bson:"filekey"`
	Size             int64   `json:"size" bson:"size"`
        CoverURL         string  `json:"coverurl" bson:"coverurl"`  / / new items
        CoverKey         string  `json:"coverkey" bson:"coverkey"`  / / new items
        // There may be more...
}

type FileArray []File
Copy the code

At present, the above structure already meets the current requirements. But are we just going to meet a single need right now? Should we be thinking bigger? Yes, as a senior R & D engineer, in addition to the need to design the best implementation scheme to meet the current needs, but also need to have high scalability in the later stage.

So the question is, if we want to query or change the name and size of the cover later, do we need to add new CoverName and CoverSize fields? If you want to download the cover, do you need to add a new CoverDownloadURL field…… This time, you will see that we actually copied all the fields of the file structure, which is obviously not reasonable.

If so, is there a better scalable solution? The answer is yes, please refer to plan two.

Plan 2: Manage the cover as a separate file and associate it with the original file

In this scheme, the cover is managed as a separate file and associated with the original video file, which can solve various problems encountered by the solution and has certain scalability. If we want to satisfy the current requirement, we simply need to add a Cover field that stores the ID of the Cover file and is used to associate the Cover file of the video file. All operations on video file covers can be converted into cover files in the later period, thus simplifying the management logic of cover files. There are many other advantages, you can think of their own supplement, welcome to the comments section.

According to the above scheme, the modified file structure:

type File struct {
	// DefaultModel adds _id, created_at and updated_at fields to the Model
	mgm.DefaultModel `bson:",inline"`
	Name             string  `json:"name" bson:"name"`
	Md5              string  `json:"md5" bson:"md5"`
	Type             string  `json:"type" bson:"type"`
	Url              string  `json:"url" bson:"url"`
	Path             string  `json:"path" bson:"path"`
	Duration         float64 `json:"duration" bson:"duration"`
	CloudUrl         string  `json:"cloudurl" bson:"cloudurl"`
	Filekey          string  `json:"filekey" bson:"filekey"`
	Size             int64   `json:"size" bson:"size"`
        Cover            string  `json:"cover" bson:"cover"`  / / new items
}

type FileArray []File
Copy the code

As you can see, scheme 2 has the least modification to the original file structure and ensures the simplicity and abstraction of the file structure. At the same time, it also meets the current demand and has certain scalability.

Conclusions and Reflections

In fact, in the daily development process, we often encounter a variety of needs, solutions are also various, we want to become a senior R & D engineer, under the premise of overall planning, looking for more in line with our system architecture implementation. Because the design and requirements of each system architecture and business line are different, it is difficult to find a unified solution. Therefore, I adhere to the principle of “there is no best but better when designing and developing implementation solutions”. The above is the thinking process I shared about the design and development of the cover requirement of an on-demand video file generation. Welcome to comment and exchange experience.